MESсирование, как
оно есть. Процессы в газовой отрасли
В статье дан краткий обзор и ввод в проблему MES, прослеживается преемственность с системами подобного класса с советских времен. Рассмотрены различные пути развития предложений
на сегодня, в том числе для непрерывных процессов. Дан критический анализ
решений. Сделан вывод в пользу отраслевых подходов.
Введение
Системы сбора и обработки
производственной информации то, что теперь называется MES, известны у нас в стране с 80-ых годов, где в общее название
АСУ так же включались и системы
управления производственными процессами.
В советский период подобными
АСУ уже ставились и разрабатывались задачи оптимального управления и
моделирования процессов производства, с целью повышения эффективности и
улучшения экономических показателей.
Сейчас это подзабыто и во
многих отраслях производства открывается вновь, как некие новинки западных
технологий, регламентирующие процесс
производства. В настоящее время эти системы выделяют в отдельный класс производственных
исполнительных систем (MES – Manufacturing Execution Systems) и определяют,
как системы автоматизированного управления
деятельностью производства или как информационно-аналитические системы
Системы класса MES призваны в режиме реального времени: отслеживать,
планировать и оптимизировать производственные
процессы от начала формирования заказа до выпуска готовой продукции с целью
повышения эффективности производства. Направлены
на информатизацию и документирование
производственных задач, их дальнейший анализ с целью выработки управленческих решений, повышение их
эффективности.
Более широко, в некоммерческой ассоциации MESA (Manufacturing
Enterprise Solutions Association), объединяющей производителей и консультантов
дано 11 основных функций MES. При
желании, можно обратиться на сайт ассоциации (http://www.mesa.org).
В общей информационной
структуре предприятия MES уровень
предполагается размещать на следующем
уровне после АСУТП и он так же должен иметь интерфейс к бизнесc-системам класса ERP. Модель трех и более
уровневого построения информационной среды предприятия можно увидеть
сейчас практически у каждого системного интегратора в области ИТ.
Сама идея получения реальных
данных с уровня технологического процесса очевидна, так как позволяет за счет их сбора, обработки и анализа,
расширить функциональные возможности ПО диспетчерского уровня. Предоставить
персоналу более широкие
возможности при принятии решений по
управлению производством, повысить их эффективность.
С другой стороны, этими
системами могут быть предоставлены
реальные данные с цехового уровня
производства с требуемым интервалом времени (минуты, часы, сутки…) на более верхние уровни в системы планирования и финансового учета.
Все-таки одной из
особенностей систем подобного класса, в отличие от типовых решений в системах ERP, должен
быть отраслевой характер построения и
функциональности системы.
Очевидно, что каждый тип
производства имеет свой характер, специфику
и вытекающие из этого различный класс задач и проблем, требующих
решения, поэтому основное внимание в
подобных системах необходимо уделять составу функциональных модулей, отраслевых
библиотек, учитывающих специфику работы предприятия.
Еще одним моментом
является учет непрерывного и дискретного
характера производства. По сути дела речь идет о конвейерном или последовательном типе
производства (автомобилестроение, пищевая промышленность..) или
производства связанным с непрерывным
движения потока сырья ( нефтегазовая отрасль,
химическая отрасль), к примеру движения
по трубопроводу углеводородов, а так же совмещение этих двух типов в одном
производстве (металлургия).
Переходя к отраслевому
проектированию и разработки систем MES уровня сам вопрос о характере
производства (непрерывный, дискретный) для заказчика может уйти на второй план,
так как система изначально будет проектироваться, и разрабатываться с
использованием только того математического обеспечения, которое
востребовано для данного производства. В этом случае системы подобного класса
могут обеспечивать реальную эффективность, реальную отдачу от вложенных
средств.
Эффективность является
основным показателем смысла всех 11 функций MES.
У нас в стране ПО, которое
было призвано автоматизировать все процессы, связанные с производственной
деятельностью, называли общей аббревиатурой
АСУП, сейчас встречаются другие
названия АСУПП (АСУ производственных процессов), а так же ОСОДУ (отраслевая система оперативно-диспетчерского
управления) и ИУС (информационно-управляющая
система) и др.
ПО этого класса задач, так же
выделяли на следующем уровне за АСУТП.
В настоящее время из
этого ПО, которое направлено на
достижение функциональности близкой к MES, можно выделить задачи связанные с
технологическим процессами и не
связанные с ТП - организационно-технического характера.
Особенностью ПО этого уровня
является то, что результат должен быть направлен на увеличение эффективности
производства на краткосрочном периоде времени в оперативном режиме и все
операции и расчеты проводятся с реальными данными, поднятыми с уровня ТП.
Какое бы не было
проектирование, можно выделить общие
составляющие подхода к таким задачам, которые требуют решения на
производственном уровне связанным с технологией и другим производственным задачам,
не связанными с технологией.
На схеме см. рис.1 отражены в
общем виде подходы к решению.
Можно сказать, что в основе функциональной структуры ПО для
технологических процессов, лежит модель, описывающая процессы данного
производства, оптимизационный расчет по выбранному критерию, анализ и вывод
отчетов, технико-экономических
показателей (ТЭП). Далее, уточнение модели или выбор других критериев и
повторение итерации, с целью достижения оптимальных ТЭП.
Блок задач
организационно-технического характера (расположен выше) обеспечивает
информатизацию и документирование процессов, связанных с производством, так
же обеспечивает контроль над заданными
регламентными процедурами производства. После получения необходимых данных из
БД, документирования и отслеживания, производится анализ накопленных
данных, сравнение графиков,
статистическая обработка и вывод необходимых ТЭП. Результаты могут коррелироваться с другой информацией по производственным
процессам из смежных блоков.
Таким образом, этот уровень
ПО прямо или косвенно может влиять на уровень
АСУТП, внесением каких-либо
уточнений в настройку системы нижнего уровня
без изменения самого технологического регламента, вносить корректировки
в ход других производственных процессов, а так же влиять на уровень ERP, обеспечивая его
реальными производственными данными.
В свою очередь с уровня ERP могут поступать плановые и экономические задания, а ПО
на этом уровне должно переводить подобные задачи в конкретное
производственное задание, смоделировать процесс и прогнозировать
результат, при необходимости обеспечить взаимодействие с уровнем АСУТП.
Ситуация
Что можно сказать о ситуации,
которая складывается сегодня с предложением
на рынке программных продуктов данного класса? Рассмотрим несколько путей.
Первый путь.
Его формируют производители SCADA
пакетов,
как об инструментарии, позволяющем решать производственные задачи любой
отрасли. Разработчику практически предоставляется интеграционная платформа, средства разработки и аналитика, сервисные
функции, решающие стандартные функции
взаимодействия и передачи информации для больших прикладных систем. С другой стороны, предоставляется платформа,
которая выросла из решения ряда
отраслевых задач, приобретенная ранее у малых фирм. Развитие таких платформ на
сегодня и определяет подобные предложения.
Для учета отраслевого
характера конкретных задач данного производства, производители подобных пакетов,
отсылает разработчика к набору функциональных библиотек, которые по сути дела и
будут той самой системой моделирования, расчета и анализа. Как правило, сам
производитель их не предлагает, но предполагает стимулировать их появление
(защитой авторских прав и затем использованием
их в составе ПО).
Насколько привлекателен такой
путь, судить программистам, технологам и математикам, которые возьмутся за разработку таких приложений.
Примером такой архитектуры служит программный комплекс «Simatic-IT» фирмы Siemens. В состав продукта
входят программные компоненты для сбора, анализа, расчетов(Historian, Production suite), моделирования
процессов(Framework), разработки клиентских WEB -приложений
(CAB) и предоставления отчетов (Report manager). Программные
продукты для поддержки операций контроля качества (Unilab) и менеджер спецификаций (Interspec), модуля поддержки периодических процессов (Batch), предназначенные для производителей продуктов
питания и напитков. Можно отметить, что вряд ли такая система универсальна и
применима ко всем типам производства, за исключением пищевой промышленности. В
комплект поставки должны входить
необходимые отраслевые библиотеки, другие необходимые функциональные модули для других производства.
Фирма WonderWare предлагает
системную платформу «System
Platform 3.0» и далее
на ее основе развитие других решений, традиционно основываясь на базе данных InSQL, в новой версии архиватор Historian, сервере
промышленных приложений IAS и ряде новых
интеграционных продуктов: информационного портала SuiteVoyager, пакета для анализа производственных данных ActiveFactory и новой концепцией Geo-SCADA, которые,
по-видимому, и будут заложены в основу будущего MES решения.
Компания GE Fanuc
предлагает менее интегрированное решение, но более функциональное на базе
программных продуктов Proficy Plant Application, архива данных iHistorian и информационного WEB- портала RTIP. В базовое
решение входят модули: управления
эффективностью (Efficiency), управление качеством (Quality), управление производством(Production) и анализ партий (Batch Analysis)
Интеграционная платформа с
аналитикой так же развивается и у
фирмы Siemens под различными марками программных продуктов для
каждой отрасли.
Важно отметить, что какую бы
не заявляли разработчики степень
интеграции в информационной среде
предприятия и функциональных возможностей ПО, для полноценного MES требуется детальная проработка решения в каждой
конкретной отрасли производства. Точнее говоря, совсем недостаточно
использование одного ранее приобретенного отраслевого решения и тиражирование
его с незначительными изменениями, под универсальную
MES, что сегодня прослеживается у поставщиков подобных
пакетов.
Обособленно стоит подход со
стороны разработчиков ERP систем, которые пытаются внести краски реальной жизни
в статичные учетно-бухгалтерские
показатели производства путем добавления
функциональных модулей, учитывающие реальные данные с уровня
производства, к примеру, модуля технического обслуживания и ремонта
оборудования (ТОиР) фирмы SAP.
Второй путь.
Он характерен для разработчиков, которые изначально выпускали прикладное ПО для
конкретной области, в которой они могут иметь свою математику, понимание
процесса, слабые и сильные стороны управления, словом задач, стоящих там.
Такие разработчики предлагают
на рынке свое прикладное ПО для решения специфичных производственных проблем для данной отрасли (нефтегазовой, металлургической
и т.д.) с конкретными решениями и
пониманием технологического процесса производства и вывода его на более
эффективные методы хозяйствования. К слову сказать, эти решения не родились
сегодня или вчера с появлением ассоциации MESA, а были продиктованы самой жизнью и пониманием круга
вопросов требующих решения. Можно сказать, что здесь уже речь идет не об
универсальной системе для любых производств, а она носит вполне ясный конкретный характер, состав задач и набор функциональных модулей
для их решения, среду разработки и взаимодействия с другими уровнями, систему моделирования
и оптимизации.
В газовой отрасли примерами
таких систем для управления газотранспортной
системой является программные комплексы PSI, SIMONE, AMADEUS-разработки западных компаний, при участии в последней
центра вычислительных технологий г. Сарова, другие отечественные системы см. далее.
Архитектура одного из
комплексов для управления нефте- и газотранспортной
системой выделяет три основных уровня – модули базового уровня, средства
оперативного управления, а также модули прикладных задач. При этом ядро системы
состоит из модулей базового уровня и
средств оперативного управления – системы SCADA и системы имитационного
моделирования.
К модулям прикладных задач
относятся:
–
управление
контрактами и ресурсами;
–
оперативного
прогноза и планирования мощностей (оптимизация работы задействованного
оборудования и агрегатов);
–
оптимизация
транспортных процессов;
–
отслеживания
партий продуктов и управление качеством;
–
функции расчета
гидравлических профилей и обнаружения и локализации утечек;
–
управления
резервуарными парками;
Модули базового уровня предоставляют систему моделирующих, управляющих и служебных функций модулям вышестоящего прикладного уровня. Для системного представления управляемого процесса со всеми его технологическими, техническими и информационными компонентами используется единая информационная модель данных.
Как отмечают разработчики,
техническими средствами стандартных систем SCADA крайне затруднительно решать
ряд специфичных задач без опоры на математическое моделирование ТП. Поэтому модули
имитационного моделирования ТП должны активно
использоваться в системах производственного
и диспетчерского управления. Во-первых,
математические модели расширяют информационный базис и повышают
достоверность информации для принятия решений по производственному и
диспетчерскому управлению. Во-вторых, имитационное моделирование, в свою
очередь, дает основу для прогнозирования
поведения системы при различных директивных воздействиях на нее
Через соответствующий интерфейс
элементы модели снабжаются информацией от КИП и директивной информацией по
процессу, полностью отображая технологическое состояние управляемой системы и
компонент автоматизации см. рис.2.
В процессе построения
математической модели, ее элементы автоматически связываются с компонентами SCADA, в том числе и с БД РВ, и архивов. Тем самым текущие
значения имитационной модели и результаты их обработки могут непосредственно отображаться
на рабочих местах и включаться в отчеты.
Рис.2 Гидравлическое
моделирование трубопровода
Стоит отметить, что
программные комплексы такого же уровня функциональности имеются и в металлургии и в автомобилестроении и
энергетике. Системы имеют четкую отраслевую направленность и никак не связаны
между собой.
Путь функциональных решений. Независимо от первого и второго пути, крупные
разработчики и отраслевые подразделения
АСУТП стремятся, наращивать свои системы
дополнительными модулями, создавать прикладные системы, обеспечивая тем самым качественно большую
функциональность, чем позволяет
стандартное ПО диспетчерского уровня. При этом они не ограничиваются
функциональностью принятой для MES.
Так силами научного
коллектива («НПО «Промавтоматика» г. Краснодар,
к.ф.-м. н. Бунякин А. В.) были разработаны ряд программных модулей для АСУ газового промысла.
Модули позволяют контролировать скважины и газосборную сеть на
предмет гидратообразования по значению вычисляемых коэффициентов
гидравлического сопротивления звеньев сети (промысловых шлейфов), а так же по расчетной
температуре во внутренних точках сети. По данным полученной модели, проверка
условия гидратообразования осуществляется
по эмпирической формуле, адаптированной к данному объекту. Критерий
оптимизации-минимизация подачи метанола. Система контроля позволяет
"заменить завышение подачи", то есть сэкономить метанол - с
одной стороны, и улучшить качество товарного газа - с другой. Модули
успешно включены в состав программного продукта диспетчерского
уровня для промысловой газотранспортной
системы. В настоящий момент идет опытно-промышленная эксплуатация этих
программных модулей на Ямбургском ГКМ.
Так же ведется работа по программным модулям «оптимизации отбора газа газового промысла» и
«обеспечения рационального использования и планирования ресурса газового
промысла». Первый модуль обеспечивает заданные расходы путем подбора
положений запорно-регулирующих устройств
(ЗРУ) на скважинах и на входе в установки комплексной подготовки газа(УКПГ) на
основе оптимизационного критерия в виде максимизации давления на входе в УКПГ, математической
модели. Второй- распределение плана добычи между скважинами газоконденсатного
промысла, согласно условий изменяющейся ситуации в газоносном пласте (смещение
уровней пластовых вод, изменение статических давлений скважин, изменение
характеристик динамической депрессии).
Основными критериями рационального использования
газового промысла были выделены: обеспечение
максимальной отдачи пласта (экономии пластового давления) на основе
выравнивания пластовых давлений, уменьшения вероятности внутрипластовых
перетоков и уменьшения вероятности обводнения забоя скважин.
Прикладные системы
В классе прикладных систем
для повышения эффективности управления газотранспортной системой нашли свое
применение и разрабатываются далее ряд отечественных
программных комплексов отраслевого характера «АСТРА», «САМПАГ», «ИНГИР», «ОКМ-РГУ» и др.
Комплексы предназначены для моделирования и оптимизации режимов
работы систем газоснабжения, в той или иной степени выполняющие задачи:
прогнозирования, анализа и повышения
эффективности технологического оборудования работы газотранспортной системы (ГТС).
Один из комплексов - отечественная разработка тюменского филиала ООО «Информгаз», «АСТРА» . Это комплекс математического
моделирования стационарных и нестационарных процессов транспорта газа.
Основной его особенностью
является комплексный подход к проблеме автоматизации управления транспортом газа,
в котором реализованы:
–
анализ
фактических режимов ГТС (расчет не замеряемых значений расходов, давлений и
температур и др. параметров) с накоплением результатов в историческую базу данных;
– планирование режимов работы ГТС, которое заключается в оптимизации режимов транспорта газа по различным критериям и передача результатов на вышестоящие уровни.
–
Прогноз
развития процесса при ручном задании управляющих воздействий (режим OFFLINE) и
расчет процесса транспорта газа (режим ONLINE).
Критериями при планировании оптимальных режимов работы ГТС являются максимум производительности и минимума эксплуатационных
затрат.
На состоявшемся ежегодном
международном конгрессе «CITOGIC» проходившем в
Базой для создания такой
системы послужил отечественный программный комплекс моделирования и оптимизации
газотранспортных систем «АСТРА».см. рис.3.
Комплекс уже установлен на
15-ти предприятиях и газотранспортных обществах.
Рис.3
Рабочие окна программного комплекса «АСТРА»
Так же в материалах на одной
из конференций «DISCOM» ( http://www.discom2002.gubkin.ru/program.html
), профессором Сарданашвили С.А. РГУ нефти и газа им. И.М.Губкина, отмечалось, что отечественные комплексы моделирования и оптимизации
режимов (КМОР) не могут конкурировать с западными
системами по показателю политической, организационной, финансовой поддержки.
Отечественные КМОР в силу этих причин не имеют такой же степени завершенности и
комплексности. Но это совершенно не означает, что Отечественные КМОР не имеют
перспективы. Отечественная научная, математическая, алгоритмическая база в
области моделирования, оптимизации, прогнозирования режимов, решения других
режимно-технологических задач не только не уступает, а во многих областях
превосходит зарубежные разработки. Уровень отечественных специалистов в области современных информационных
технологий, проектирования и программирования КМОР ни кем не ставится под
сомнение.
Итоги
Автор статьи не проводил
подобные исследования в других отраслях н/х, но есть предположение, что и там
имеются такие же отраслевые системы, комплексы, программные модули, призванные
планировать, оптимизировать, отслеживать и документировать деятельность
производства с целью повышения эффективности управления на производственном
уровне. При желании читатель может самостоятельно выделить подобное ПО в данном
классе задач. Вопрос MESсирования не
столько вопрос нового ПО, а сколько вопрос правильного понимания и выделения уже созданного и апробированного ПО.
Поэтому, учитывая выше приведенные
мнения и востребованность таких задач,
на примере газовой отрасли, перспектива
такого подхода очевидна. Разработчики, сами того не осознавая, двигаются по
пути внедрения приложений функционально близких к MES системам в терминах и понятиях
европейского комитета MESA, и совсем
не очевидно, что Европа здесь будет
законодателем мод.
Это
вполне естественный путь, который был
прерван в нашей стране периодом реформ 90-ых. Путь, который имеет
непосредственное отношение ко второму аспекту понимания проблемы,
стимулирующему разработку необходимых функциональных модулей-библиотек и
законченных отраслевых прикладных систем, которые затем могут быть встроены в
другую приобретенную платформу
разработчика или расширенны до системы диспетчерского управления ОСОДУ, ИУС и
как итог, выделится в законченный уровень,
который в Европе начинают называть MES.
Подводя
итог статьи, следует, что второй путь и связанные с ним отечественные
разработки, а так же западные системы, проектируемые под конкретную отрасль с
присущим им функционалом, имеют наибольшую перспективу для развития и
предоставления сервисов уровня MES. Системы
диспетчерского уровня, отмеченные в первом аспекте, в силу своей нацеленности на решение более
общих задач, не в состоянии на данный момент предложить требуемую
функциональность в данном классе задач.
Кузьмин Юрий Борисович
Литература.
1. Справочник разработчика АСУ, Модин
А.А., Яковенко Е.Г., Погребной Е.П.,
изд-во «Экономика»,
