1225
.pdfРис. 12.17. Структура полей информационного сообщения в ГПС
Представим один из популярных вариантов такого языка для ГПС. Единица сообщения – кадр, длина которого не превышает 512 байт. Структура полей информационного сообщения представлена на рис. 12.17.
Х – тип передачи, в числе которых A, C, D, E, N, U:
A – уведомление об отказе передатчика от передачи;
C– передача команды запроса;
D– передача данных, причем не последнего блока передаваемого по частям файла;
E– передача данных, причем последнего или единственного блока;
N– отказ от передачи по инициативе приемника по причине не-
возможности выполнить какую-то команду или неверно принятой информации;
U – запрос на незапланированную передачу по инициативе передатчика (запланированная передача – по инициативе приемника, нуждающегося в передаче).
Дальнейшая детализация содержания сообщения осуществляется введением подтипов передачи:
NAM (name) – имя файла или программы;
STA (status) – статус, т.е. описание состояния объекта; MSG (message) – электронная почта (экранное сообщение); EXE (execution) – инициация выполнения;
FIL (file) – признак файла.
Очередной шаг уточнения содержательной части сообщения состоит в указании форматов данных или в использовании расширений команды. Установлены следующие форматы данных:
BCL (binary cutter location data) – информация об инструменте; BIN (binary data) – информация в двоичном коде;
221
ISO – управляющая программа в коде ISO; INS (inspection data) – результаты измерения; TST (test data) – тесты.
Расширения команды привязаны к подтипам передачи.
Так, подтип STA имеет расширения: ALL (передается полный набор данных); CYC (состояние автоматического цикла); INH (состояние блокировки); PRG (состояние отработки программы); ALM (признак аварийного останова) и др.
Подтип EXE имеет расширения: ARP (обращение к локальной системе ГПМ); CCP (задание коррекций на инструмент); CRT (обращение к устройству управления транспортным робокаром); AUT (обращение к режиму «автомат»); CYC (обращение к автоматическому циклу); LDR (задание роботу на загрузку заготовки); PLT (задание на идентификацию определенной палеты); PRT (задание на идентификацию определенной детали); UGP (разжим); ULP (разгрузка) и т.д.
Подтип FIL имеет расширения: CLO (закрыть файл); DEL (стереть файл); DIR (обращение к справочнику); RED (считать файл); REN (переименовать файл); WRT (записать файл).
Расширения имеет и тип N (подтипы в этом случае не используются): CNE (команда не выполнена); DNA (данные недоступны); DNR (данные не готовы); FLU (файл в работе); FNA (файл недоступен); FNF (файл не найден); FNI (функция не реализована); FNO (файл не открыт); MNQ (сообщение отсутствует); PNF (пакет, т.е. блок сообщений, не найден); SMF (запоминающее устройство заполнено); SNQ (данные о состоянии неизвестны); SNR (система не готова).
Синтаксические диаграммы передач и сессий см. в [12].
Более подробно о ЛВС и промышленных шинах можно узнать из пособия [10].
222
Контрольные вопросы
1.Приведите структурную схему типовой АСУТП на основе рассмотренных различных примеров реальных АСУТП.
2.Как реализуется нижний уровень АСУТП?
3.Каковы принципы доступа к локальной сети в АСУТП?
4.Перечислите принципы организации физического, канального сетевого уровня локальных сетей.
5.Приведите примеры синтаксиса в промышленных ГПС для транспортного и сессионного уровней передачи информации.
6.Каковы характерные особенности АСУТП «Проконтроль», «Даматис ХР», «ТДС 3000», «Micon», «Квинт»?
223
13. АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ КОНТРОЛЯ И УЧЕТА ЭНЕРГОРЕСУРСОВ (АСКУЭ)
13.1. ТРЕБОВАНИЯ К АВТОМАТИЗИРОВАННЫМ
СИСТЕМАМ КОНТРОЛЯ И УЧЕТА ЭНЕРГОРЕСУРСОВ
Высокая стоимость энергоресурсов в последние годы стала причиной того, что отношение к организации энергоучета в промышленности и других энергоемких отраслях (транспорт и жи- лищно-коммунальное хозяйство) кардинально изменилось. Потребители начинают осознавать, что в их интересах рассчитываться с поставщиком энергоресурсов не по каким-то условным нормам, договорным величинам или устаревшим и неточным приборам, а на основе современного и высокоточного приборного учета. Промышленные предприятия пытаются как-то реорганизовать свой энергоучет «вчерашнего дня», сделав его адекватным требованиям дня сегодняшнего. Под давлением рынка энергоресурсов потребители приходят к пониманию той простой истины, что первым шагом в экономии энергоресурсов и снижении финансовых потерь является точный учет. С этой целью как поставщики, так и потребители создают на своих объектах автоматизированные системы контроля и учета энергоресурсов (АСКУЭ). При наличии современной АСКУЭ промышленное предприятие полностью контролирует весь свой процесс энергопотребления и имеет возможность по согласованию с поставщиками энергоресурсов гибко переходить к разным тарифным системам, минимизируя свои энергозатраты.
На ряде предприятий АСКУЭ функционируют уже не один год, на других предприятиях начинается их внедрение, а руководители третьих только размышляют, нужно ли им это. Ход развития мировой энергетики и промышленности показывает, что альтернативы
224
принципу «все надо учитывать и за все надо платить» нет. И если сегодня где-то еще удается бесконтрольно пользоваться энергоресурсами или списывать потери в сетях на потребителя, то завтра это станет попросту невозможно. Преимущества будут у того, кто все процессы энергопотребления полносью контролирует.
Постоянное удорожание энергоресурсов требует от промышленных предприятий разработки и внедрения комплекса мероприятий по энергосбережению, включающих жесткий контроль поставки/потребления всех видов энергоресурсов, ограничение и снижение их доли в себестоимости продукции. Современная АСКУЭ является измерительным инструментом, позволяющим это осуществить, и лежит в основе системы энергосбережения промышленных предприятий. Первый и самый необходимый шаг в этом направлении, который надо сделать уже сегодня, – это внедрить автоматизированный учет энергоресурсов, позволяющий контролировать параметры всех энергоносителей по всей структурной иерархии предприятия с доведением этого контроля до каждого рабочего места. Благодаря этому будут сведены к минимуму производственные и непроизводственные затраты на энергоресурсы; это позволит решать спорные вопросы между поставщиком и потребителем энергоресурсов не волевыми, директивными мерами, а на основании объективного автоматизированного учета.
Итак, можно выделить следующие основные цели создания АСКУЭ.
1.Автоматизированные системы контроля и учета энергоресурсов при минимальном участии человека на этапе измерения, сбора
иобработки данных должны обеспечить достоверный, точный, оперативный и гибкий, адаптируемый к различным тарифным системам учет как со стороны поставщика энергоресурсов, так и со стороны потребителя.
2.На основе достоверной и оперативной информации можно принять решение по диспетчерскому или автоматическому управлению, чтобы снизить максимумы мощности, выбрать оптимальный уровень энергопотребления для различных технологических режи-
225
мов или суточного/недельного графика, управлять компенсирующими установками реактивной энергии и другими энергопроизводящими установками.
3. По результатам анализа энергопотребления при использовании современных СУБД можно составлять энергобалансы на год, 5 лет и более с целью определения потребности в энергии предприятия в целом и наиболее энергоемких агрегатов и цехов, проводить анализ эффективности использования энергоресурсов, выявлять непроизводительные расходы и потери, находить норму расхода энергии на единицу продукции и обеспечивать снижение энергопотребления.
4. Коммерческий и технический учет поставки/потребления энергоресурсов позволяет экономически обоснованно разрабатывать и осуществлять комплекс мероприятий по энергосбережению, своевременно его корректировать, обеспечивая динамическую оптимизацию затрат на энергоресурсы в условиях изменяющейся экономической среды.
До последнего времени под АСКУЭ понимались в основном контроль и учет электроэнергии. Поэтому иногда АСКУЭ распознают как «Автоматизированные системы контроля и учета электроэнергии» или «Автоматизированные системы коммерческого учета электроэнергии». Однако в перспективе на предприятиях и в сфере ЖКХ будет востребован контроль и учет всех видов энергоресурсов: тепловой энергии, холодной и горячей воды, природного газа, сжатого воздуха и т.д. Системы контроля и учета отдельных энергоресурсов различаются между собой незначительно. Поэтому принимаем под АСКУЭ «Автоматизированные системы контроля и учета энергоресурсов».
В настоящее время выпускается множество систем АСКУЭ. Имеется тенденция в каждом регионе разработать «свою» АСКУЭ. Учитывая множество устройств сбора информации от датчиков с импульсными, аналоговыми, цифровыми выходами, множество систем передачи информации, комплексов программного обеспечения для систем сбора, обработки, хранения, визуализации, передачи информации, пользователи АСКУЭ бывают в затруднении при выборе КТС и ПО.
226
Рассмотрим систему учета и управления энергоресурсами среднего предприятия.
Основной пользователь системы – отдел главного энергетика – желает оперативно получить следующую информацию:
коммерческий учет тепловой, электрической энергии, газа, воды, сжатого воздуха и т.п. на вводах в предприятие;
коммерческий учет энергоресурсов, отпускаемых субабонентам; технический учет энергоресурсов на вводе в отдельные цеха или на входе/выходе отдельных энергопроизводств (котельных, ком-
прессорных, насосных и т.д.); контроль (телемеханика) режимов работы оборудования и со-
стояния электрических сетей (ток, напряжение, частота) на заводских подстанциях;
контроль за теплотехническим оборудованием завода (положение задвижек, состояние клапанов);
телеуправление (возможно автоматическое) электротехническим и теплотехническим оборудованием.
К этим требованиям добавляются требования от энергетиков цехов и мастеров (технических руководителей) различных энергообъектов (котельных, компрессорных и т.д.) по организации учета расхода энергоресурсов и контроля параметров энергоресурсов на конкретных технологических объектах (например, расход газа на металлургическую печь или котел, электроэнергии на насос и т.д.). При этом необходимо, чтобы, с одной стороны, система учета включала в себя функции оперативного контроля параметров энергоносителей, а с другой стороны – чтобы функции оперативного контроля состояния оборудования и сетей (функции телемеханики) были дополнены возможностью ретроспективы (восстановления) состояния оборудования и параметров за любой период времени. Фактически получается, что к системе учета и к системе телемеханики предъявляются во многом схожие требования: возможность оперативного контроля и архивирования параметров энергоресурсов и состояния оборудования. Несомненно, эти функции могут выполняться любой стандартной системой сбора данных.
227
Но коммерческий учет предъявляет повышенные требования к сохранности и достоверности информации. Выражается это в том, что:
системы учета должны вести расчеты и архивирование информации на нижнем уровне (уровень счетчиков или тепловычислителей), системы учета должны иметь сертификаты Госреестра на из-
мерение параметров энергоносителей, оборудование должно соответствовать требованиям по огра-
ничению несанкционированного доступа, пломбированию и т.д.
На этапе обследования предприятия, изучения установленного парка счетчиков, датчиков, преобразователей (полевой уровень), условий эксплуатации вместе со специалистами КИПиА (или АСУ ТП) появляются требования и к среднему уровню – уровню тепловычислителей, устройств телемеханики, УСПД; для упрощения назовем все это контроллерами:
контроллеры должны быть проектно компонуемыми на необходимое число каналов ввода-вывода;
контроллеры должны работать с очень широким спектром входных сигналов – от «естественных» сигналов термопар и термосопротивлений до «кодовых» сигналов «интеллектуальных» датчиков, счетчиков, модулей ввода-вывода;
контроллеры должны уметь считать расходы по различным алгоритмам, в зависимости от типов установленных преобразователей и счетчиков (от диафрагм до ультразвуковых расходомеров);
контроллеры должны иметь возможность гибкой перенастройки и конфигурации персоналом на различные преобразователи, счетчики, датчики и виды энергоносителей;
контроллеры должны иметь возможность автоматического управления исполнительными механизмами. Для конфигурации каналов управления не должно требоваться программирование контроллеров;
контроллеры должны иметь гальваническую изоляцию всех каналов ввода-вывода, в том числе и коммуникационных – требование, выработанное многолетней практикой;
контроллеры должны соответствовать промышленным условиям эксплуатации, это подразумевает требования и по температуре
228
окружающей среды, и по пылебрызгозащищенности, по качеству электропитания, по возможным перенапряжениям на каналах вводавывода и т.д.;
контроллеры должны иметь развитые коммуникационные возможности. «Джентльменский набор» – это промышленная сеть на базе RS-485 и дополнительно еще один последовательный порт для локального подключения или использования с модемами различных типов. Желательна поддержка основных промышленных сетей
FieldBus (Modbus, Profibus, CANopen, AS-i и др.), ЛВС типа Ethernet
с протоколом TCP/IP.
Разрабатываемая АСКУЭ должна интегрировать существующие «локальные» системы учета, если они работают и не стоит вопрос об их замене.
Кроме энергетиков, требования к системе выставляют и службы, непосредственно занимающиеся АСУ ТП. На некоторых предприятиях это могут быть отделы АСУ и КИПиА, на других – объединенный отдел АСУ ТП. Важно, что по распределению функций внутри предприятия эти службы являются исполнителем, ответственным перед заказчиком (отделом главного энергетика) за выбор подрядчика, качество и сроки работ. Поэтому и требования к внедряемой системе с их стороны достаточно жесткие: им за нее отвечать и ее эксплуатировать.
Рассмотрим типовые требования к верхнему уровню системы – уровню баз данных, сетей и АРМ. Как правило, на предприятии уже существует корпоративная сеть, зачастую используются современное оборудование и технологии, которые обслуживают финансовые, складские и прочие задачи, не относящиеся к АСУ ТП. По принятой терминологии такие системы называются АСУ производством (АСУП) и самостоятельно разрабатываются специалистами предприятия либо покупаются. В любом случае специалисты предъявляют требования, чтобы верхний уровень внедряемой системы легко интегрировался в уже существующую сеть, и даже если это будет ка- кая-то локальная подсистема, то и организация баз данных, и выбор операционных систем, и сетевое взаимодействие компонентов, и дизайн АРМ должен соответствовать уровню предприятия и тем стан-
229
дартам, которые там используются. Можно представить требования, которым должно соответствовать программное обеспечение верхнего уровня подобной системы:
используемые операционные системы – в большинстве случа-
ев это Windows 98/NT/2000 и выше;
единая база данных на стандартных СУБД, причем все чаще требуются не «настольные» СУБД (Paradox, Access), а мощные SQL базы данных (MS SQL 7.0, Oracle), которые могут одновременно обслуживать десятки АРМ и гарантируют достоверность и сохранность информации;
использование клиент-серверной технологии взаимодействия между АРМ и сервером баз данных, причем клиенты должны быть «тонкими», то есть все основные вычисления (бизнес-логика) происходят на сервере баз данных или на специализированном сервере приложений, а АРМ конкретных приложений больше используются как терминалы, что также гарантирует сохранность и достоверность данных;
встроенные возможности администрирования и конфигурирования программного обеспечения, обеспечение защиты от несанкционированного доступа к информации (дополнительно к стандартным возможностям Windows NT и SQL сервера);
полная и подробная документация, позволяющая программистам предприятия разрабатывать собственные приложения, используя существующие «хранимые процедуры» и базы данных;
интеграция существующих узлов учета в систему, причем на верхнем уровне это должна быть полная интеграция, то есть единые базы данных, единые АРМ, единые отчеты;
разделение доступа клиентов (АРМ) к базе данных.
13.2.УРОВНИ АСКУЭ
Вструктуре АСКУЭ, как пример конкретной реализации АСУ ТП
вэнергетике, в общем случае можно выделить четыре уровня (в малых и средних по мощности АСКУЭ может быть два или три уровня).
230