что такое теги в асу тп
От измерения и обработки тегов к объектам и быстрой разработке автоматизированных систем
В настоящее время системы диспетчеризации, оперативного управления производством (MES) и интеллектуальные системы предприятия обеспечивают сбор, обработку и визуализацию данных о технологических процессах, рассчитывают производственные показатели, формируют отчеты, а также ведут историю и сохраняют данные в базах.
С момента своего появления эти системы прошли путь от измерения и обработки тегов до создания и тиражирования объектов, связанных с определенным ресурсом или оборудованием.
Объектно-ориентированная архитектура позволяет реализовать типовой подход к разработке автоматизированной системы контроля и управления, при котором на основе дублирования и объединения объектов из предметно-ориентированных библиотек формируется законченная система. Применение данных механизмов к разработке систем диспетчеризации и управления технологическими процессами позволяет значительно сократить сроки выполнения инжиниринговых работ и облегчить поддержку решений в будущем. Именно такой подход реализован в SCADA/HMI DataRate.
Объектная модель и предметно-ориентированные библиотеки
Основой архитектуры DataRate является объектная модель (рис.1), которая содержит:
Рис. 1. Объектно-ориентированная архитектура SCADA/HMI DataRate
Разработку автоматизированных систем обеспечивают средства быстрой разработки DataRate, а также объекты и сервисы промышленной автоматизации. Мастера создания и настройки объектов позволяют значительно ускорить процесс создания систем и автоматизируют ряд типовых функций. Добавить новый элемент на мнемосхему можно, перетащив его мышкой из соответствующей библиотеки. Точно так же можно добавить новый объект в библиотеку.
SCADA/HMI DataRate позволяет работать с набором шаблонов технологических объектов (включающих виды, теги, скрипты), которые объединены в библиотеки. В составе дистрибутива поставляется системная и две предметно-ориентированные библиотеки.
Рис. 2. Структура библиотеки объектов энергоучета
Библиотека объектов учета энергоресурсов
Библиотечный объект содержит вид прибора, панель выбора параметра и индикацию текущего значения выбранного параметра. Например, для счетчика электроэнергии на мнемосхеме объекта отображаются: накопленная потребленная активная/реактивная энергия; текущая потребляемая активная/реактивная мощность по трем фазам; текущая потребляемая полная мощность по трем фазам и др. Таким образом, объект «счетчик» позволяет осуществлять мониторинг и контроль потребления энергоресурса по конкретному прибору в заданный интервал времени.
Данная библиотека содержит объекты приборов учета наиболее популярных на рынке энергопотребления производителей (рис.2), таких как Нижегородский завод имени М.В. Фрунзе, «Энергомера», «ИНКОТЕКС», «Саранский приборостроительный завод», НПО «ВЗЛЕТ», НПФ «ТЭМ-Прибор», НПФ «Теплоком», «ТЕПЛОВОДОХРАН» и др. Библиотека постоянно расширяется выпускаемыми новыми приборами и предоставляет пользователям возможности для быстрого построения систем АСТУЭ/АСКУЭ.
Библиотека объектов электрических схем
Библиотека предназначена для создания, просмотра, распечатки и хранения нормальных и оперативных схем электрических соединений в проектах автоматизированных систем контроля и управления в энергетике.
Объекты элементов электрических схем разделены по функциональному назначению на несколько групп: устройства с неизменяющимся состоянием, трансформаторы (двух- и трехобмоточные), реакторы, линии электропередачи и сборные шины, устройства с изменяющимся состоянием (коммутационное оборудование с состояниями «Включен/Отключен»). Также в библиотеке содержатся паспорта устройств для каждой группы объектов.
Системная библиотека
В SCADA/HMI DataRate 4.1 была полностью обновлена системная библиотека. Новая структура дерева библиотеки четко разделяет объекты по их функциональному назначению. Системная библиотека содержит групповые аналитические тренды, панель переходов, удобные и информативные индикаторы (табло, термометры, стрелочные приборы, барограф и др.), элементы управления автоматизированных систем (переключатель, регулятор, кнопка, радиокнопка, флажок и др.) и отдельные объекты. Объекты новой версии системной библиотеки позволяют разрабатывать графические проекты с современным и понятным интерфейсом диспетчера.
Типовые проекты и примеры внедрений
Типовые проекты DataRate (рис. 3) для ускоренной разработки АИИС ТУЭ на основе предметно-ориентированных библиотек объектов ориентированы на приборы учета «Меркурий 230», СЕ-301, СЕ-303, СЭТ-4ТМ.02, СЭТ-4ТМ.03, ПСЧ-4ТМ.05 (и других, производства НЗиФ), ElNet MC и обеспечивают выполнение следующих функций:
Рассмотрим несколько примеров внедрений автоматизированных систем, построенных с использованием DataRate.
Рис. 3. Пример структуры типового проекта автоматизированной системы учета энергопотребления
Центр сбора технологической информации (ЦСТИ)
ЦСТИ Нижнекамской ТЭЦ построен на основе программного обеспечения WideTrack и SCADA/HMI DataRate. Система предназначена для сбора, обработки и визуализации технологических параметров локальных АСУ ТП Нижнекамской ТЭЦ: восемь АСУ ТП котлоагрегатов (рис. 4), семь АСУ ТП турбин, 37 АСУ ТП общестанционного оборудования.
Рис. 4. Мнемосхема АСУ ТП котлоагрегата
Отличительной особенностью системы является консолидация технологических данных от SCADA различных производителей, в т.ч. SCADA КРУГ-2000, Siemens Win CC, Trace Mode, Ovation и др.
Система автоматизации линии экспандирования комбикормов
Автоматизированная система экспандирования комбикормов ОАО «КХП им. Григоровича» (г.Челябинск, объединение «СоюзПищепром») позволяет осуществлять контроль на каждом из этапов обработки комбикорма, начиная от экспандирования, сушки комбикорма и до финальной обработки и отпуска готовой продукции (рис. 5).
Рис. 5. Фрагмент главного окна системы автоматизации линии экспандирования комбикормов ОАО КХП им. Григоровича
Одной из особенностей данной системы является работа со сложными Batch-процессами (вид технологического процесса, который предусматривает работу с рецептурами). В зависимости от рецептуры взаимосвязанно меняются не только количество и виды используемых компонентов, но и технологический процесс обработки комбикорма на разных участках.
Автоматизированная система технического учета электроэнергии (АСТУЭ)
АСТУЭ ОАО «Трубодеталь» (г. Челябинск) включает в себя 59 счетчиков электроэнергии, расположенных на электрических подстанциях, от которых осуществляется электроснабжение ключевых участков производства, девять контроллеров сбора данных, серверное оборудование. Визуализация данных на АРМ осуществляется при помощи DataRate. Специалистам отдела главного энергетика и энергоцеха предоставляется возможность удаленного просмотра данных системы.
АСТУЭ позволяет осуществлять анализ баланса потребления электроэнергии по производственным участкам. Для этого DataRate предоставляет механизм перегруппировки счетчиков без остановки работы АИИС ТУЭ (рис. 6).
Рис. 6. Мнемосхема с детальной информацией со счетчика электроэнергии
Заключение
SCADA/HMI DataRate — это современное и эффективное программное обеспечение для создания систем автоматизации, отличающееся простотой в эксплуатации и рассчитанное на пользователей с самым разным уровнем подготовки. Широкие функциональные возможности, открытость и обширная практика внедрений позволяют использовать DataRate в решениях разнообразных задач автоматизации, в том числе и для контроля специфических и сложных производственных процессов.
Тегом называется текстовая строка (описатель), уникальным образом идентифицирующая структуру данных, которая связана с одним, входным, выходным или внутренним, сигналом в системе сбора данных и управления.
Любая текстовая строка, определяющая источник данных и не являющаяся числовым значением, а также не обозначенная специальными символами идентификации, описание которых приведено ниже, интерпретируется в GraphWorX32 в качестве тега.
Если требуется использовать имена тегов, целиком состоящие из цифр, следует применять следующий синтаксис: <<имя_тега>>
Все теги GraphWorX32, для которых не определены или отсутствуют реальные источники данных, в режиме Исполнение отмечаются как недействительные.
Щелчок левой клавишей мыши на кнопке Теги ОPC или ОPC в Инспекторе свойств выводит на экран монитора Навигатор тегов ОРС, внешний вид которого показан на рисунке 41. Навигатор тегов предназначен для поиска, просмотра и выбора требуемого тега для установления соединения клиентского приложения GENESIS32 с соответствующим источником данных.
Рисунок 41 – Навигатор тегов OPC.
GraphWorX32 автоматически определяет, что введенная строка, идентифицирующая источник данных, является числовым значением, и интерпретирует такую строку, как константу.
При необходимости ввода строковой константы следует использовать следующий синтаксис:
Применение данного синтаксиса приводит к тому, что GraphWorX32 не воспринимает введенную строку как имя тега.
Локальной называется такая переменная GraphWorX32r непосредственный доступ к значению которой возможен только в пределах экранной формы, в которой она объявлена. Значения локальных переменных GraphWorX32 не могут передаваться в другие экранные формы или в другие приложения GENESIS32, включая управляющий элемент ActiveX просмотра графиков, без принятия специальных мер. Наиболее простой способ передачи значений локальных переменных другим приложениям GENESIS32 состоит в использовании Сервера вторичной обработки данных DataWorX32.
Локальные переменные GraphWorX32 обозначаются следующим образом:
Как правило, локальные переменные используются в качестве источников данных для различных анимационных эффектов в экранных формах GraphWorX32.
Встроенный динамический объект Значение параметра (Параметр) 
Данный динамический объект позволяет создавать в экранных формах алфавитно-цифровые индикаторы, на которых в режиме Исполнение отображаются значения связанных источников данных. Кроме того, указанный динамический объект может одновременно являться полем, в которое оператор вводит требуемые значения, которые должны передаваться связанному источнику данных в режиме Исполнение.
Обновление значений, отображаемых динамическим объектом Параметр, производится по извещению от QPC-сервера об изменении связанного с ним тега ОРС.
Если объект одновременно используется в качестве поля ввода данных, то, помимо отображения значений связанного источника данных, имеется возможность ввода оператором и передачи значений соответствующему источнику данных.
Для создания объекта Значение параметра:
1. Выберите строку Значение параметра подменю Встроенные объекты меню Динамика или нажмите кнопку Значение параметра 
панели инструментов Динамика.
2. Щелкните левой клавишей мыши в точке экранной формы, в которой требуется создать динамический объект Значение параметра. На экран монитора будет выведена диалоговая панель Инспектора свойств с выбранной закладкой Параметр, внешний вид которой показан на рисунке 42
3. Введите имя тега, локальной переменной или псевдоним в поле Источник данных или воспользуйтесь кнопками Теги ОРС или Меню тегов для указания имени источника данных.
4. Если требуется использовать объект в качестве поля ввода значений для передачи связанному источнику данных, установите флажок Ввод данных в группе Тип параметра.
5. Если необходимо только вводить значения, одновременно не запрашивая их у связанного источника данных, снимите отметку флажка Значение и установите флажок Ввод данных.
Чтобы распечатать файл, скачайте его (в формате Word).
Промышленное программирование, или Пара слов об АСУ ТП
Есть такая профессия — производство автоматизировать. Аббревиатура АСУ ТП означает «автоматизированная система управления технологическим процессом» — это система, состоящая из персонала и совокупности оборудования с программным обеспечением, использующихся для автоматизации функций этого самого персонала по управлению промышленными объектами: электростанциями, котельными, насосными, водоочистными сооружениями, пищевыми, химическими, металлургическими заводами, нефтегазовыми объектами и т.д. и т.п.
Фактически, каждый человек, живущий не в лесу и пользующийся благами цивилизации, использует результаты труда предприятий, на которых функционируют АСУ ТП.
Иногда на эту тему проскакивают статьи и на хабре. Обычно они не пользуются особой популярностью, но всё же я хочу написать несколько обзорных статей об АСУ ТП в надежде рассказать хабравчанам что-то интересное (а возможно, кому-то даже полезное) и привлечь на хабр больше своих коллег.
Сначала пара слов о себе. Я только начинаю свой жизненный путь в автоматизации, опыт работы без малого два года. За это время побывал на нескольких газовых месторождениях, сейчас работаю на нефтяном.
Поскольку область обширная, несмотря ни на что развивающаяся, местами противоречивая и спорная, буду стараться обобщать не в ущерб достоверности, но не могу избежать перекоса в свою область — то оборудование, софт и сферу, с которыми лично я сталкивался.
Итак, программно-технический комплекс АСУ ТП делится на три уровня: верхний (компьютеры), средний (контроллеры), нижний (полевое оборудование, датчики, исполнительные механизмы). Про нижний уровень рассказывать не буду — слишком уж это далеко от от тематики хабра, да и статья получится слишком большая.
Верхний уровень
Верхний уровень — это серверы и пользовательские ПК (у нас они называются АРМ — автоматизированное рабочее место). Сюда выводится состояние технологического процесса, и отсюда при необходимости оператором подаются команды на изменение его параметров. Для упрощения разработки создано большое количество SCADA-систем (от англ. supervisory control and data acquisition — диспетчерское управление и сбор данных). Это в некотором роде расширенный аналог IDE, в котором скомпилированная «программа» и выполняется.
Системы SCADA
Вообще, если отбросить академизм, то на предприятии для всех кроме асушников скада выглядит вот так: 
А если совсем не повезёт, то вот так: 
Подразумеваются два режима функционирования: режим разработки и режим выполнения (runtime). Не обязательно эти режимы взаимоисключающи: можно редактировать проект на одном АРМе, инженерном, заливать его, он обновится на пользовательских. Это очень важно — изменять проект без простоев и отключений, потому что технологический процесс прерывать нельзя, и операторы всегда должны иметь возможность его контролировать. В скаде создаются графические интерфейсы, настраиваются источники данных с полевых устройств, она отвечает за взаимодействие пользователя (оператора, диспетчера, технолога) с происходящим на производстве, а также за архивирование всех нужных данных в БД.
Архивирование — одна из обязательных функций, очень важно иметь возможность «вернуться назад во времени» для разбора полётов в случае чего-то непредвиденного либо для глобального анализа при медленных, длительных процессах. Например, недавно геологи попросили меня выгрузить табличкой данные по давлению нефти на скважинах за последний год.
Периодически скада складывает все собранные данные в БД. Их потом можно посмотреть в виде графиков (называем их трендами), а при необходимости, если оговорено в ТЗ на АСУТП, реализуется выгрузка в виде отчётов в эксель или ещё как-нибудь. Архивация сделана по-разному: в MS SQL; MS Access; в ту же MS SQL, но по своему хитрому алгоритму с дополнительной архивацией; а у кого-то вообще в свою собственную бинарную БД.
Особым пунктом в скадах идёт информирование оператора: текущие сообщения и аварийные. Они тоже обязательно архивируются. В общем виде сообщения делятся на текущие и важные (аварийные). Текущие прячут подальше, но журнал аварийных всегда выводится на экране оператора. К текстовым аварийным сообщениям привязываются звуковые, чтобы кто-нибудь не проспал ЧП 🙂
Рынок SCADA
Самыми распространёнными, по-моему, считаются скады производства Invensys Wonderware, Iconics, Siemens, Indusoft, AdAstra, Emerson, Rockwell Automation.
Я лично работал с виндовыми: Invensys Wonderware InTouch и более мощной System Platform, с Iconics Genesis32 — и с (пока ещё?) малоизвестной B&R APROL под SLES (формально, это не совсем скада, а покруче — из-под апрола программируются и сами контроллеры).
По поисковым запросам, например, SCADA, HMI можно посмотреть примеры интерфейсов и мнемосхем.
Внешний вид и юзабилити по приоритету, увы, находятся на последнем месте. Причём, это касается не только рантайма, но и разработки. Для разработки в каждой скаде существуют как минимум дефолтные библиотеки символов — от кнопок и прочих контролов до графических изображений насосов, труб, задвижек, ёмкостей. Здесь-то и могли бы умные разработчики SCADA-пакетов (не путать с нами, асушниками — разработчиками проектов в этих пакетах) добиться принципиального преимущества над конкурентами, сделав продуманные библиотеки, из которых бы даже самый далёкий от дизайна и юзабилити инженер при всём нежелании делал бы гуманные интерфейсы и мнемосхемы. К сожалению, сейчас эта сфера идёт по пути экстенсивного развития, по которому развивалась IT до недавнего времени — наращивание функционала, добавление плюшек, больше, выше, сильнее, harder, better, stronger, и о пользователях пока думают мало.
Средний уровень
Средний уровень — ПЛК, программируемые логические контроллеры. Здесь всё достаточно просто, чаще всего физически ПЛК состоят из отдельных модулей. Для программирования у каждого ПЛК есть своя среда разработки, иногда она объединена со средой для создания SCADA.
Состав ПЛК
Контроллер B&R серии X20
Зачем нужен блок питания — понятно. БП сделан отдельным именно модулем, а не устройством, чтобы гарантировать совместимость с данной линейкой ПЛК. Чаще всего входное напряжение у БП 220 В переменного тока, выходное — 24 В постоянного тока.
Процессорный модуль — это голова ПЛК. Внутри у него, само собой, ЦПУ, ОЗУ и ПЗУ, сервисный порт для прошивки и, возможно, коммуникационный порт (ethernet, RS232/422/485, Profibus, etc). Иногда коммуникационный порт используется и как сервисный. Иногда на модуле есть переключатель (у Allen Bradley ещё круче — там натуральный ключ с замочной скважиной) для перевода ПЛК в различные режимы работы. Отдельной кнопки включения/выключения нет, в лучшем случае — тот переключатель, иначе, если есть питание — ПЛК запускается, а выключается и перезагружается «по-варварски» отключением питания.
Контроллер Allen Bradley серии CompactLogix
Дискретные и аналоговые модули обрабатывают соответствующие сигналы. Входные модули принимают эти сигналы с поля, выходные — формируют их.
Дискретный сигнал — это обычно напряжение цепи 24 вольта. Есть 24 — это «1», нет — «0». Бывают модули на 220В, есть модули с проверкой целостности цепи. Дискретные сигналы, приходящие с поля, могут информировать, например, о состоянии насоса включен/выключен. Управляющие дискретные сигналы могут запускать либо останавливать этот насос. Оптимизация здесь не оправдана, поэтому на запуск будет отдельная цепь, на останов — отдельная.
Модули I/O одного типа могут быть объединены: например, один модуль с 16 дискретными входами и 16 дискретными выходами.
Аналоговые входные сигналы — это приходят показания с датчиков. Здесь чаще всего используется токовая петля 4-20 мА, в соотетствие которой ставятся пределы измерения датчика. Начинается от 4 мА для диагностирования обрыва цепи (если меньше 4 мА, значит где-то что-то не в порядке с проводкой).
Рассмотрим на примере уровня жидкости в резервуаре. Стоит уровнемер, он измеряет уровень от 0 до 2 метров. Тогда: уровень 0 метров — это 4 мА, уровень 2 метра — это 20 мА. Промежуточные значения калибруются по ситуации, не всегда 1 метр соответствует 4+(20-4)/2=12 мА, может быть небольшая погрешность, уровень в 1 метр может быть какие-нибудь 12,7553 мА.
Аналоговые выходные — то же, только на управление. Не встречал чтобы использовалось, т.к. всегда существуют наводки. В измерении это допустимая погрешность, в управлении — нет. Да и неудобно это. Вместо них используется цифровая передача данных по различным протоколам через коммуникационные модули.
Температурные модули замеряют сопротивление в цепи либо термо-ЭДС. Если на них подключаются термометры сопротивления — при нагревании металла его сопротивление, по законам физики, повышается, соответственно определяется температура. Если подключается термопара (два спаянных проводника из разных металлов, при нагревании стыка возникает разность потенциалов между другими концами), замеряется напряжение.
Интерфейсные (или коммуникационные) модули предоставляют нам порты под RJ45, DB9, DB15, просто клеммники или что ещё бог производителю на душу положит. Помимо реализации непосредственно интерфейса (физического разъёма под коннектор, физического уровня модели OSI) они также реализуют протокол обмена через этот разъём.
Протоколы и интерфейсы
Протоколов напридумывали и используют кучу: ModBus (RTU, TCP, ASCII), Profibus, Profinet, CAN, HART, DF1, DH485 и т.д. Некоторые особо хитрые производители реализуют свои протоколы поверх общепринятых.
Я достаточно тесно знаком с интерфейсами RS232/485 и протоколами Modbus. RS232 это всем знакомый COM-порт, с тремя основными линиями: Tx (transmit, передача), Rx (recieve, получение) и GND (ground, земля). RS485 это асинхронный полудуплексный последовательный интерфейс по 2 проводам (совмещённые Tx/Rx+ и Tx/Rx-) или 4 проводам (отдельно Tx+, Tx-, Rx+, Rx-) с разностью потенциалов на каждой паре от 2 до 10 вольт.
А модбас это в общем-то нехитрая штука, с проверкой целостности пакета по чексумме, подтверждением доставки и корректности запроса — или ответом, почему запрос неверен. В сети модбас есть два вида устройств: master — инициирует обмен; slave — выполняет запросы мастера. Пакет от мастера расходится ко всем слейвам, которые сравнивают адрес назначения со своим, если сходится, то смотрят следующие два байта — это команда работы с регистрами памяти — чтение/запись (за исключением нескольких редко используемых служебных команд), потом байты адреса и непосредственно данных, в конце чексумма. Достаточно подробно и понятно расписано на википедии.
Программная начинка
Первое, что нужно сказать, программа в ПЛК выполняется циклически с определённой частотой. Возможности зависят от контроллера, обычно это где-то 20, 50, 250 мс, 1, 2, 3, 4, 5 с. Естественно, это не гарантирует выполнение кода именно за такой промежуток времени, нельзя большие программы пихать в цикл 20 мс, к началу следующего цикла предыдущий должен быть завершён.
Второе, это языки программирования. По идее программируются ПЛК на языках, определённых стандартом МЭК61131:
Это «по идее». Но, например, Siemens придерживается своего наименования языков, а у B&R есть возможность писать на ANSI C.
Самые используемые контроллеры, безоговорочно, у Siemens и Allen Bradley (последним, к слову, принадлежит Rockwell Automation со своей линейкой SCADA-пакетов RSView). За ними по пятам идут Schneider Electric; ОВЕН; General Electric; AutomationDirect; ICP DAS; Advantech; Mitsubishi Electric; B&R.