Проблемы создания интегрированных систем управления

 

Оглавление

Введение 2

1. Проблемы создания интегрированных систем 2

2. Организационные проблемы 2

3. Технические проблемы 2

4. Проблемы развертывания 2

5. Администрирование пользователей и ресурсов 2

6. Операционная доступность 2

7. Интегрированная ИС предприятия 2

8. Программные средства ИСУ 2

9. Программные пакеты для АСУ ТП 2

Заключение 2

Список  используемой литературы 2

 

Введение

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

 

  1. Проблемы  создания интегрированных систем

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

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

 

  1. Организационные проблемы

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

      В то же время бывшее ранее общепринятое понятие АСУП постепенно стало уступать место другим понятиям — «ERP-системам» и «автоматизации бизнес-процессов». Однако подобные новации не сближают АСУП с действующими на предприятии АСУ ТП, содержащих всю производственную информацию.

     Эксплуатация, внедрение и модернизация АСУ  ТП на предприятии обычно осуществляется группой специалистов (отдел, сектор, департамент АСУ ТП), входящих в  состав цеха КИПиА или в службу Главного метролога.

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

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

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

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

 

  1. Технические проблемы

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

     На  современном этапе развития автоматизации  управления бизнес-процессами (АСУП) создается  и широко внедряется большое количество типовых программных систем управления ресурсами предприятия. К таким  системам, ориентированным на бизнес-анализ, относятся: SAP R/3, Baan, Oracle Applications, jD Edward’s, MFG-Pro, Syteline, iRenaissance, Concorde XAL, Axapta, SunSystems, Босс-Корпорация, Галактика, Парус, Ресурс и др.

     Особенностью  всех этих систем является применение современных реляционных баз  данных, таких как, например, Oracle, Informix, Microsoft SQL Server и др., которые наиболее хорошо приспособлены для решения многокомпонентных задач анализа. Внедрение подобных систем с большим или меньшим успехом осуществляется на многих отечественных предприятиях нефтегазового комплекса.

     Различные поставщики программных продуктов  типа DCS и SCADA (ABB, Fisher Rosemount, Foxboro, Honeywell, Intellution, Wonderware и др.) продолжают развивать и совершенствовать свои системы, успешно применяемые в АСУ ТП. Их особенностью является то, что они работают с объемными потоками данных о технологических процессах, поступающих от большого числа (нескольких сот или тысяч) датчиков в реальном масштабе времени и с высокой частотой опроса (до тысячи раз в секунду и чаще). Такие данные необходимы не только для оперативного управления технологическим процессом, но и для анализа, позволяющего оптимизировать как отдельные технологические процессы, так и производство в целом.

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

 

  1. Проблемы развертывания

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

     По  данным опроса IDC, ИТ-менеджеры тратят в среднем 190 часов в месяц на процесс развертывания систем для 100 пользователей. Половина этого времени  уходит на инсталляцию и расширение прикладного ПО. Естественно, менеджеры  заинтересованы в повышении эффективности  этих операций с помощью автоматизированных средств управления развертыванием. Сегодня основные решения в этой области включают: диски быстрого старта (quickstart disk), которые используются для ускорения начальной установки клиентских и серверных машин; приложения автоматизированного распознавания аппаратного и программного обеспечения, которые позволяют осуществлять быстрый начальный учет ресурсов и автоматизируют модификации; продукты электронного распределения ПО, реализующие передачу файлов по локальным и глобальным сетям на множество настольных компьютеров и серверов.

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

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

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

     Использование интегрированных сред управления в  процессах развертывания позволяет  почти вдвое сократить затрачиваемое  на эти задачи время. Представим себе, например, администратора, который  решает задачу распределения ПО в  клиент/серверной системе отдела корпорации. При этом клиентские компоненты приложения должны выполняться на ПК с Windows 95 и Unix, а серверные - на машинах с NT и Unix. Управляющая система с простой поддержкой множества вычислительных платформ будет передавать приложение с Windows на Windows и с Unix на Unix, и только кросс-платформенное решение способно распределять ПО из единого хранилища на все необходимые системы одновременно с помощью одного управляющего приложения, учитывая при этом конкретные требования данной платформы. Примером такого управляющего приложения может служить Tivoli ТМЕ 10 Courier, которое, действуя вместе с модулем управления ресурсами ТМЕ 10 Inventory, позволяет развертывать приложения по всем разнородным компонентам информационной системы предприятия, от центров данных на базе мэйнфреймов до Web-серверов, и гарантирует не только корректную инсталляцию ПО, но и его правильное функционирование.

 

  1. Администрирование пользователей и ресурсов

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

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

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

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

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

       Таким требованиям удовлетворяют интегрированные  системы управления. По данным IDC, выполнение административных операций в интегрированной  среде позволяет более чем  вдвое снизить затрачиваемое  на эти задачи время для 100 пользователей. Для примера: управляющее приложение TME 10 User Administration задает единый шаблон для учетных данных пользователя на разнородных системах и позволяет модифицировать эти данные с помощью только одной операции.

 

  1. Операционная  доступность

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

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

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

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

       IDC провела опрос среди различных  компаний, проанализировав время,  которое ежемесячно тратится  на выполнение операций по 11 дисциплинам  управления до использования  каких-либо автоматизированных средств,  после инсталляции отдельных  управляющих систем и в случае  использования интегрированного  решения (Таблица 1). Оказалось, что даже развертывание неинтегрированных продуктов позволило добиться экономии времени в среднем на 10%, а интегрированная система снизила на 39% количество часов, которые уходят на поддержку операционной доступности системы.

       Таблица 1. Время, затрачиваемое на управляющие операции до и после реализации системы управления 

  1. Интегрированная ИС предприятия

     На  уровне бизнес-процессов необходима только интегрированная информация о технологических процессах. В  частности, данные типа «нарастающим итогом», средних значений за определенные промежутки времени, общее количество произведенных  продуктов и т.д. Очевидно, что  подобные данные должны поступать в  систему гораздо реже, чем данные реального времени от технологических  процессов. Из-за несогласованности  природы и назначения данных верхнего (АСУП) и нижнего (АСУ ТП) уровней  управления между ними необходим  промежуточный интегрирующий слой, который мог бы служить мостом между столь разнородными потоками данных.

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

На рис. 1 приведена обобщенная схема ИСУ  предприятием.

 

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

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

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

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

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

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

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

 

  1. Программные средства ИСУ

     Сегодня на российском рынке программные  средства для создания интегрированных  систем управления представлены продуктами таких фирм, как AspenTech (Info+), Honeywell (РHD), OSIsoft (PI System) и др. Анализ функциональных возможностей и опыта эксплуатации показал, что наиболее известным и функционально развитым из программных продуктов этого назначения является пакет Plant Information System (PI System).

     Дружественный интерфейс, а также высокая надежность программного продукта, непрерывный  процесс поддержки пользователей  и продуманная политика регулярных обновлений привели к тому, что  PI System заняла ведущее место в мире среди продуктов этого класса. Сегодня PI System используются на 70% зарубежных нефтеперерабатывающих предприятий, оснащенных ИСП, среди которых Shell, Exxon, Texaco и другие мировые нефтегазовые лидеры.

     В России PI System работает на Омском (НК «Сибнефть»), Новокуйбышевском (НК «ЮКОС»), Сызранском (НК «ЮКОС»), Куйбышевском (НК «ЮКОС») НПЗ, в «ЛУКОЙЛ-Пермнефтеоргсинтезе».

     Типовая структура информационной системы  производства, построенной на базе PI System, представлена на рис. 3.

     

     Являясь гибким инструментом для создания информационной системы производства, PI System позволяет при помощи интерфейсов получать данные от:

     • распределенных систем управления (DCS);

     • систем операторского контроля, сбора  данных и управления (SCADA);

     • непосредственно от контроллеров (PLC);

     • лабораторных систем (LIMS);

     • устройств ручного ввода.

     Наличие большого выбора (более 300) интерфейсов  для разных систем АСУ ТП позволяет  PI System создать единое информационное пространство производства.

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

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

     PI System обеспечивает надежный механизм  построения ИСП, но эта система  оперирует уже «готовыми» данными  из АСУ ТП. И здесь необходимо  быть уверенным, что данные, предоставляемые  SCADA-системами, достоверны, своевременны и точны. Таким образом, АСУ ТП есть необходимая база построения ИСУ НК, основной источник производственной информации. Поэтому наряду с выполнением функции диспетчерского управления системы данного уровня должны обеспечивать целостность и надежную доставку данных технологического характера.

       
 
 

 

  1. Программные пакеты для АСУ ТП

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

Проблемы создания интегрированных систем управления