Системы SCADA/DCS
Системы ERP/MRP II и MES
Чего не хватает в пирамиде?
На пути к интеграции

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

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

Приступим к "инвентаризации". Вспомним, что и как делалось на предприятиях в последние годы. Итак, были реализованы отдельные задачи, в основном на больших ЭВМ серии ЕС — клонах мэйнфреймов IBM — и отечественных аналогах мини- и микрокомпьютеров СМ ЭВМ, "Электроника-60", ДВК. (Не будем вспоминать ужас вычислительных центров "Наири".) Век рапортов: режимные листы оператора, ТЭПы, ведомости на зарплату, учет товаров на складах. (Режимные листы оператора — статистические характеристики технологического процесса, ТЭП — технико-экономические показатели.)

Теоретические попытки классифицировать решаемые задачи привели к разделению их на две группы:

• технологические производственные;
• экономические, административные и логистические.

Системы SCADA/DCS

В сегодняшней интерпретации "нижнюю" группу задач в иерархии управления производством относят к системам типа SCADA (Supervisory Control and Data Acquisition) или DCS (Distributed Control Systems). Оба указанных типа систем принадлежат классу MMI (Man-Machine Interface), что означает "человеко-машинный интерфейс" в смысле обеспечения двусторонней связи "оператор — технологическое оборудование". Системы MMI все чаще называют HMI (Human-Machine Interface). Это не меняет существа дела, но снимает легкую дискриминацию по отношению к женскому полу (Man по-английски и человек и мужчина).

Вечные проблемы с переводом! Если делать его дословно, то технический термин часто превращается в абракадабру. Если "олитературить" перевод подбором близких терминов, то скоро станет непонятно, с чем мы, собственно, имеем дело. Если оставлять английские термины, то забываешь, на каком языке написан текст. Особенно вредны аббревиатуры, имеющие одинаковое написание, но разный смысл. Его, конечно, можно "выудить" из контекста, но уж больно противно вместо разбора сути дела решать шарады и ребусы. Уважаемые любители аббревиатур! Вы даже не представляете, как раздражает читателя их обилие! Но как же быть? Предлагаю отчасти волюнтаристский подход: руководствоваться общепринятыми нормами там, где они определены, и собственным (где взять другой?) здравым смыслом — там, где их нет.

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

Теперь относительно SCADA и DCS. Я сомневаюсь, что эти два наименования обозначают одно и то же. К сожалению, встречающиеся в литературе идентификации систем меня не удовлетворяют. После тщательного рассмотрения доводы авторов рассыпаются, как карточные домики, и оказывается, что никакой разницы между системами нет. Единственное, в чем я уверена, так это в том, что одни фирмы представляют свои продукты как системы SCADA, а другие — как DCS. Ниже приведена встречающаяся в специализированной литературе классификация этих систем в зависимости от фирмы-производителя.

Классификация систем АСУТП

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

Итак, первая группа задач управления промышленным предприятием — то, что в СССР именовалось АСУТП (Автоматизированные системы управления технологическими процессами).

Я совсем забыла упомянуть о группе задач программирования логических контроллеров PLC (Programmable Logic Controller). Эти задачи, естественно, относятся к сфере АСУТП и реализуются чаще всего с использованием методики Ladder Logic, которая представляет собой специализированный язык, близкий по типу к мнемонике электрических схем.

Системы ERP/MRP II и MES

Системы второй группы относятся к классу ERP (Enterprise Resource Planning) — планирование ресурсов предприятия или MRP II (Manufacturing Resource Planning) — планирование ресурсов производства. Системы ERP ориентированы на предприятие в целом, а MRP — на его технологические подразделения. Если опять-таки вспомнить нашу старую терминологию, то это задачи АСУП (Автоматизированные системы управления предприятием).

Нельзя не сказать несколько слов о САПР (Системах автоматизированного проектирования), без которых не могло обойтись ни одно промышленное предприятие, чья продукция требует конструкторской документации. Современные технологии САПР для предприятий представлены системами CAD/CAM/CAE/PDM (Сomputer Aided Design, Manufacturing, Engineering, Product Data Management). Эти системы позволяют обойтись без "бумажной" документации, осуществляя прямую связь между процессами разработки изделия и его производства, что позволяет повысить качество продукции и сократить период разработки.

Постепенно между MMI и ERP образовалась промежуточная группа систем, называемая MES (Manufacturing Execution Systems). Она возникла вследствие обособления задач, не относящихся ни к одной из ранее определенных групп. К системам MES принято относить приложения, отвечающие:

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

Второй путь возникновения систем MES — снизу, от АСУТП. Так произошло отделение тактических задач оперативного управления технологическими процессами от стратегических задач ведения процесса в целом. В частности, в химической, металлургической, пищевой и некоторых других отраслях промышленности можно выделить задачи управления технологическими последовательностями (batch control). Их суть — в обеспечении выпуска продукции в нужном объеме с заданными технологическими характеристиками при наличии возможности перехода на новый вид продукции. Отделились и задачи ведения архива значений технологических переменных с возможностью восстановления производственных ситуаций прошедших периодов и анализа нештатных ситуаций. Появились программы обучения технологического персонала и оптимизации ведения технологических процессов.

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

Чего не хватает в пирамиде?

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

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

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

Существует еще один важный аспект этой проблемы: информационные технологии стареют намного быстрее, чем производственное оборудование. "Железо" устаревает в среднем через 6—12 месяцев после выхода на рынок. Период появления новых версий современных информационных систем — один год. Вместе с тем в промышленности до сих пор применяются ЭВМ 70-х годов. Я уж не говорю о датчиках, исполнительных механизмах, кабельном хозяйстве и пр. Необыкновенно стремительное развитие информационных технологий — большая проблема для промышленности. Предприятие не может себе позволить менять все измерительное оборудование каждые несколько лет. Выход один — постепенная частичная замена устаревшей техники. Что же тогда? Поменял приложение — пиши новый драйвер? Готовь "заплатки" к десяткам программ? Или, покупая новый пакет, ищи только тот, который сможет встроиться в твою информационную среду?

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

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

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

На пути к интеграции

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

Прежде всего напомним, что задачу объединения АСУТП и АСУП условно относят к системам уровня MES. Стремление связать системы типа SCADA/DCS с системами верхнего уровня ERP/MRP II существовало всегда. Однако в процессе развития различных промышленных приложений выявились участки, где обеспечение обмена данными представлялось особенно перспективным и интересным, например: между CAD-системами и ERP/MRP II, между ERP/MRP II и подсистемами ведения архива значений технологических параметров, между системой SCADA и подсистемами контроллеров и т. д. В этом смысле правильнее было бы представить техническое решение, обеспечивающее взаимодействие приложений, как "программный слой", с которым другие системы имеют двустороннюю связь.

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

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

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

Еще один нюанс — период обновления программных продуктов в промышленности намного больше. Здесь пока нет своего аналога Microsoft, который диктовал бы такой стремительный темп развития. Скорее всего, таковой и не появится из-за невозможности охватить столь огромный и неоднородный рынок. Однако, несмотря на очевидные подводные камни, положительный опыт стандартизации офисных пакетов неизбежно открывает путь введения стандартов на разработку промышленных приложений. Под этим не следует понимать переход к использованию одной операционной системы, базы данных или сетевого протокола, например TCP/IP, поскольку все это никоим образом не гарантирует возможности обмена данными между промышленными приложениями.

Первым шагом в направлении стандартизации была попытка создать однородные протоколы для связи с производственным оборудованием. В начале 80-х годов корпорация General Motors разработала протокол автоматизации производства MAP (Manufacturing Automation Protocol). В его основе лежит идея стандартного коммуникационного стека и генерации сообщений в едином формате. Несмотря на вес General Motors на мировом рынке, протокол MAP так и не получил всеобщего признания: он очень сложен и требует больших вычислительных ресурсов. Идея стандартизации "затаилась" почти на 15 лет.

Современные решения в области стандартизации связаны прежде всего с фирмой Microsoft. Это в первую очередь технология OPC (OLE for Process Control), т. е. OLE (Object Linking and Embedding) для технологического управления. Она представляет собой стандартный метод для доступа к периферийным устройствам, системам SCADA/MMI или другим промышленным приложениям, основанным на технологиях OLE, COM (Component Object Model) и DCOM (Distributed COM). В общих словах OPC представлена набором стандартных объектов, методов и свойств, отвечающих требованиям промышленных приложений реального времени. Эти требования включают в себя синтаксис для доступа к объектам, эффективную передачу данных от оборудования к приложениям, способность клиента работать с несколькими серверами одновременно и поддержку конфигурации сервера. Программные пакеты на основе OPC легко интегрировать в бизнес-приложения, поддерживающие OLE.

Первая версия OPC вышла в 1995 г. Она не претендовала на стандарт, но была призвана сыгратьроль пробного камня для всех заинтересованных сторон. Основной упор был сделан на сбор данных. Более сложные задачи: сигнализация (оповещение о наступлении технологических событий), отслеживание трендов (последовательностей значений параметров, отражающих поведение технологического процесса), моделирование — отложены на будущее. В том же 1995 г. появилась независимая некоммерческая организация OPC Foundation. Цель ее деятельности централизация управления разработкой нового стандарта. В настоящее время она объединяет около 250 компаний, среди которых Fisher-Rosemaunt, Rockwell Software, Intellution.

К сожалению, набор продуктов, разработанных по новому стандарту, весьма и весьма ограничен. Сегодня судьба OPC — в руках производителей промышленных приложений. Только они смогут выпустить доброго джина стандартизации из бутылки. И тогда счастливые пользователи избавятся от головной боли, как связать воедино то, что они уже имеют или будут иметь. Хватит ли у Microsoft сил, терпения, упорства и средств, чтобы обеспечить “зеленую улицу” своему детищу? Сможет ли компания, имеющая такое исключительное влияние на компьютерный рынок, совершить революцию и в автоматизации промышленности?

Последний "хит" от Microsoft в этой области анонсирован в сентябре 1997 г. Имя ему — Windows DNA (Windows Distributed interNet Applications Architecture). Эта архитектура также основана на объектно-ориентированной COM-технологии создания функциональных пользовательских компонентов. Новая идея — разработка спецификаций по отдельным отраслям и сегментам промышленности (Vertical Industry Specifications) — не лишена логики и позволит сконцентрироваться на нескольких областях производства, где наиболее популярны программные продукты, поддерживающие COM. Это можно расценивать как признание поражения всех попыток выработать общий промышленный стандарт.

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

После неудачи General Motors на пути стандартизации для решения задачи интеграции был создан консорциум, в который вошли крупные автомобильные производители (Renault, Mercedes-Benz и др.), представители авиационной промышленности и некоторые фирмы бытовой электроники (Bosch, Siemens Automation и др.). Он получил название AIT (Advanced Information Technology). С его помощью была разработана интеграционная платформа CCE (Common Computing Environment). Данная среда позволяет приложениям независимо от протоколов, операционных систем, баз данных и методов доступа общаться друг с другом. Развитие этой идеи привело к возникновению архитектуры CORBA (Common Object Request Broker Architecture), также одобренной консорциумом AIT.

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

Но не все так хорошо, как кажется. Отметим некоторые недостатки внедрения связующего ПО:

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

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

Консорциум OMG (Object Management Group), основанный в 1989 г., взял на себя труд разработать теорию объектно-ориентированной технологии для развития распределенных компьютерных систем. Основное направление деятельности консорциума можно сформулировать так: развитие общей архитектурной платформы для объектно-ориентированных приложений на основе открытых спецификаций. Его девиз звучал бы, наверное, более патетически: "Архитектура для объединения мира".

Сначала в OMG входило всего 13 компаний, сейчас их число выросло до 500. Это поставщики, разработчики и пользователи компьютерных технологий. Можно сказать, что все компании, заинтересованные в разработке объектно-ориентированных подходов, являются членами OMG.

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

Версия 1.1 спецификации CORBA была выпущена OMG в 1991 г. В ней были определены язык описания интерфейса (Interface Definition Language — IDL) и интерфейсы прикладного программирования (Application Programming Interfaces — API), сделавшие доступным взаимодействие клиент—объект в среде ORB. Суть модели в следующем. Клиент запрашивает сервисы у объекта (который выступает в качестве сервера) через хорошо определенный интерфейс (последний специфицирован в IDL). Для доступа к объекту клиент создает запрос, т. е. сообщение, содержащее информацию о действии, ссылку на сервис, параметры.

Спецификация CORBA 2.0, "родившаяся" в декабре 1994 г., определила информационный обмен между приложениями различных фирм. Она добавила к уже освоенным высотам возможность обмениваться данными через Интернет по протоколу IIOP (Internet Inter-ORB Protocol) и платформенную независимость. Ее внедрение позволяет пользоваться преимуществами Интернет без перестройки промышленной системы.

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

И все-таки архитектура OMG/CORBA более зрелая, чем OPC и тем более Windows DNA. Уже существуют многочисленные ее реализации, применение которых в промышленности делает приложения независимыми от используемых устройств, сетей, операционных систем и компьютеров. Возникают заманчивые перспективы свободного развития приложений, с одной стороны, и общей инфраструктуры — с другой. Правда, если наступит эра всеобщей стандартизации по версии Microsoft, то CORBA останется не у дел. Но, пока она не наступила, CORBA, пожалуй, лучшее решение для объединения в единый комплекс автоматических систем управления различных уровней с учетом того, что некоторые из них устарели, а другие не подчиняются никаким стандартам и предлагают уникальные решения.

Третий путь — вполне самостоятельное направление, цель которого — удовлетворить в одном "сверхпродукте" или комплексе продуктов одной фирмы-производителя все потребности современного промышленного предприятия — своего рода скатерть-самобранка от автоматизации. Многие фирмы — производители систем SCADA движутся сейчас в этом направлении, и мне кажется, что больше всех здесь преуспела фирма Wonderware, выпустившая продукт FactorySuite. Кроме возможностей систем SCADA, в нем реализованы функции Batch Control, программирование логических контроллеров, ведение проектов, контроль качества продукции и некоторые функции автоматизации административного управления. Фирма Intellution, помимо систем SCADA, предлагает пакет типа Batch Control и пакеты с Интернет-функциями. Список фирм можно продолжить. Но все их предложения еще так далеки от полного комплексного решения задач автоматизации. Трудно представить, чтобы в ближайшее время появилась компания, способная решить все задачи предприятия на современном техническом уровне. Но кто знает?..

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

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

Дополнительную информацию Вы можете получить в компании Interface Ltd.