CC BY
352
ИНТЕГРАЦИЯ СИСТЕМ АВТОМАТИЗИРОВАННОЙ ПОДГОТОВКИ ПРОИЗВОДСТВА В ЕДИНОМ ИНФОРМАЦИОННОМ ПРОСТРАНСТВЕ
В.В. Богданов
Научный руководитель - д.т.н., профессор Д.Д. Куликов
В статье рассматриваются возможности интеграции систем автоматизированной технологической подготовки производства в единое информационное пространство предприятия при помощи современных средств обеспечения межпрограммного взаимодействия.
Введение
Современная методология автоматизации технологической и конструкторской подготовки производства подразумевает внедрение на предприятии целого комплекса программных средств, начиная от различного рода САПР и заканчивая РБМ- и ЕЯР-системами. В условиях использования значительного количества разнообразного программного обеспечения возникает необходимость в организации единого информационного пространства предприятия и интеграции в него всех использующихся на предприятии средств автоматизации обработки и хранения информации. На сегодняшний день решение проблемы обеспечения интеграции программного обеспечения в единую информационную структуру предприятия является одной из важнейших задач 1Т-персонала множества предприятий. Решения, внедряемые на предприятиях, во многом основываются на предыдущем опыте сотрудников 1Т-персонала и, зачастую, не удовлетворяет требованиям, предъявляемым к современным системам автоматизированной подготовки производства. Для определения возможных путей решения проблемы интеграции автоматизированных систем подготовки производства был произведен общий анализ всех существующих на сегодняшний день методов интеграции подсистем автоматизированной подготовки производства в едином информационном пространстве предприятия. Результаты анализа и предложения по применению некоторых технологий приведены в данной статье.
Постановка задачи
В условиях жестких требований рынка к сокращению сроков проектирования и подготовки производства, к повышению качества изделий необходим выход на качественно новый уровень компьютеризации конструкторской и технологической подготовки производства. Этот уровень обеспечивает применение СЛЬБ-методологии, суть которой состоит в непрерывной информационной поддержке разработчиков на всех этапах жизненного цикла изделия (ЖЦИ). Стратегическое решение задачи перехода к СЛЬБ-технологиям предполагает применение интегрированных решений по следующим направлениям [1]:
• сквозная компьютеризация всего спектра инженерных задач в проектировании и подготовке производства, с выбором базовых СЛВ/СЛМ/СЛЕ-систем и поддержкой необходимых форматов данных для обмена конструкторской и технологической информацией;
• организация единой базы данных проекта для поддержки всех этапов ЖЦИ, компьютеризация управления проектированием и подготовкой производства на основе применения РБМ-систем;
• учет фактора кооперации предприятий при работе над проектом. Применение специальных средств, поддерживающих оперативный обмен конструкторско-
технологической информацией между заказчиком и исполнителем, процессы коллективного принятия решений.
Одной из основных задач в рамках применения СЛЬБ-методологии является интеграция всех данных, получаемых с помощью различных СЛВ-систем. На предприятиях, где доля конструкторского проектирования с использованием СЛВ-систем уже весьма значительна, специалистами и специализированными фирмами в рамках крупных проектов выполняется значительный объем работ по преобразованию форматов данных и созданию системы информационного взаимодействия. Однако отработка информационного взаимодействия разных систем с использованием нейтральных форматов или прямых интерфейсов - только часть решения проблемы. Большую сложность представляет интеграция всей информации (результатов деятельности всех специалистов), с обеспечением возможности ее многократного использования. На практике по-прежнему всю информацию выводят на бумажные носители, и это объясняется, в том числе, и неготовностью участников процесса принять информацию в электронном виде, неспособностью служб технической документации управлять электронными архивами и т.д. Решение этой проблемы создатели СЛЬБ-технологий видят в применении РБМ-систем [1]. Информация, создаваемая на этапе технической подготовки производства, составляет большую часть общей информации ЖЦИ. Сюда входит информация конструкторских проектов изделий основного производства и конструкторских проектов оснастки для изготовления этих изделий, информация технологических процессов изготовления изделий и технологических процессов изготовления оснастки, информация о стандартных изделиях и материалах и т.д. Вся эта информация формируется в различных системах. Большинство существующих сегодня систем разрабатывались как автономные, и вследствие этого при интеграции их с другими системами необходимы серьезные доработки с привлечением высококвалифицированных программистов. Для успешной реализации внедрения РБМ-системы необходимо обеспечить возможность взаимодействия этих систем как с РБМ-системой, так и между собой. Дополнительно к этому, в рамках применения СЛЬБ-методологии для автоматизации производства необходимо предусмотреть возможность кооперации предприятий при работе над проектом. Это подразумевает под собой организацию системы обмена информацией не только в рамках предприятия, но и между различными предприятиями, участвующими в проекте. Таким образом, задача может быть разделена на 2 этапа: объединение подсистем автоматизации подготовки производства внутри предприятия, и организация обмена информацией между предприятиями.
Анализ существующих решений
Процесс обеспечения интеграции информационных подсистем предприятия в единую информационную систему сильно зависит от применяемого программного и аппаратного обеспечения. Каждое предприятие уникально. Одни программные средства могут обладать большими возможностями для интеграции, чем другие. Потенциальная выгода от интеграции информационных систем предприятия обычно выше для больших предприятий. На сегодняшний день существует и успешно применяется несколько подходов к обеспечению интеграции приложений. Различия между этими типами интеграции приложений предприятия основаны на том, где применяются эти подходы. Основные стратегии и точки интеграции включают в себя следующее [2]:
• интеграция источников данных;
• интеграция прикладных интерфейсов программирования;
• интеграция бизнес-логики.
В процессе интеграции информационных систем предприятия могут одновременно использоваться несколько подходов к интеграции, если это необходимо. В некото-
рых случаях представляется невозможным использовать те или иные средства для интеграции ПО. Это зависит от программно-аппаратной среды предприятия.
Метод интеграции, основанный на использовании общих источников данных, предполагает создание единой системы обработки и хранения данных предприятия. Приложения должны хранить данные в одном из существующих хранилищ данных. Основная масса существующих на сегодняшний день приложений использует в качестве хранилища данных реляционные системы управления базами данных. Информация извлекается из источника данных автоматически, трансформируется в соответствии с потребностями бизнес-процессов и заносится в другую БД [2]. Для обеспечения успешной интеграции источников данных необходимо четко представлять себе структуру метаданных, хранящихся в БД информационных систем. Должны быть известны схемы баз данных и значение различных полей данных, которые подвергаются изменениям. Простая операция обновления данных может потребовать внесения изменений в несколько базах данных и множество таблиц. В некоторых случаях необходимыми являются некоторые представления о процессах, происходящих внутри приложения. Это затрудняет процесс интеграции. Метод интеграции, основанный на использовании общих источников данных, часто оказывается самым дешевым. Средства и методы обмена информацией хорошо развиты в современном мире информационных технологий и сравнительно дешевы по отношению к другим методам интеграции приложений предприятия.
Метод интеграции, основанный на использовании общих прикладных интерфейсов программирования (API), использует программные интерфейсы, предоставляемые различными приложениями в качестве точки интеграции. В зависимости от предоставляемых программным продуктом API бизнес-логика и процессы приложения могут быть такими же доступными, как и данные. Этот подход к интеграции наиболее подходит для больших приложений (таких, как PDM- или ERP-системы), содержащих сложную бизнес-логику и большие недокументированные или сложные для понимания базы данных [3]. Например, PDM-система SmarTeam может использовать в качестве хранилища данных различные СУБД (такие как Oracle, DB2 или Microsoft SQL Server), что дает широкие потенциальные возможности для интеграции с другими системами на основе общего источника данных. Но метаданные базы данных могут быть комплексны, что очень сильно затруднит процесс интеграции с использованием общих источников данных без потенциальных нарушений целостности БД и системы SmarTeam в целом. Поэтому система предоставляет целый набор API, которые могут использоваться в качестве точки интеграции. Значительным недостатком этого подхода является то, что процесс интеграции ограничен теми API, которые предоставляются разработчиками ПО. Одни приложения могут иметь огромный набор программных интерфейсов, предоставляющих доступ практически ко всем объектам приложения, другие же могут иметь очень ограниченный набор API. Для обеспечения своему приложению конкурентоспособности большинство разработчиков стремится соблюсти баланс в предоставлении API и доступа к логике приложения. Поэтому зачастую необходимые для интеграции API могут не входить в состав того или иного приложения. Кроме того, несмотря на то, что разработчики предоставляют API для интеграции своего приложения, эти API могут быть реализованы с помощью устаревших методов, а также быть достаточно сложными для понимания и корректного использования.
Метод интеграции, основанный на использовании бизнес-логики, обычно требует наиболее распространенных изменений в приложениях. Цель заключается в совместном использовании бизнес-логики, принятой в компании. Например, изменение какой-либо информации может затронуть несколько приложений. Используя распределенную бизнес-логику, можно создать единые методы управлении информацией, которые будут распределены между всеми приложениями, которым необходимы эти функции [2].
Если происходят изменения в логической структуре приложений, то внесение изменений в программный код производится централизованно. Недостатком этого метода является то, что необходимо вносить изменения во все существующие приложения.
Предлагаемое решение
На сегодняшний день существуют различные информационные технологии, которые позволяют реализовать описанные выше методы интеграции программного обеспечения и различные их комбинации. В качестве таких технологий можно привести технологии CORBA, DCOM или SOA [3]. Исходя из того, что активы программного обеспечения и опыта его внедрения на разных предприятиях различны, требуется найти как можно более универсальные методы для обеспечения информационной интеграции программной среды предприятия. На сегодняшний день достигнуть достаточной универсальности позволяет применение технологии веб-сервисов. Веб-сервисы представляют собой технологию, основанную на применении свободно связанных компьютерных систем, которые предоставляют сервисы друг для друга. Это позволяет создать среду межпрограммного взаимодействия, которая очень слабо зависит от того, какие приложения используются в этой среде. Назовем основные особенности веб-сервисов.
• Веб-сервисы разработаны для обеспечения взаимодействия одних программных модулей (объектов) с другими. Соединенные приложения предоставляют сервисы для обмена информацией или выполнения бизнес-логики.
• Веб-сервисы используют стандарты XML (extensible markup language) для обмена информацией. Стандарт XML является универсальным средством для представления информации и обмена ею.
• Решения, основанные на технологии веб-сервисов, являются легко масштабируемыми.
• Веб-сервисы используют общепринятые стандарты internet. Это дает огромное преимущество перед другими технологиями, поскольку стандарты internet применяются во всем мире и не зависят от программной и аппаратной среды.
SOA (Service-oriented architecture, сервис-ориентированная архитектура) - распределенная вычислительная окружающая среда, разработанная, чтобы, в том числе, обеспечить возможность сравнительно быстрой адаптации и интеграции различных приложений. SOA обладает достаточной гибкостью, чтобы рассматривать элементы бизнес-процесса и основную инфраструктуру IT как безопасные, стандартизированные компоненты, которые могут многократно использоваться и объединяться, чтобы адекватно отображать изменяющиеся приоритеты [3]. Основной SOA является всесторонний набор программного обеспечения для управления информационными потоками и процессами обмена информацией, необходимый для координирования сервисов. В качестве примеров таких программных продуктов можно привести Microsoft BizTalk Server или IBM WebSphere Business Integration Server. Эти приложения базируются на современных программных платформах Java 2EE или Microsoft .NET и имеют встроенную поддержку для работы с веб-сервисами. Такие программные продукты имеют 2 сценария применения [3]:
• интеграция приложений внутри одного предприятия (EAI, Enterprise Application Integration);
• интеграция приложений, обслуживающих различные предприятия (B2B, Business to business integration).
На рис. 1 приведена схема, по которой реализуется процесс EAI. Каждое приложение, участвующее в процессе интеграции, связывается со службой обмена сообщениями, которая входит в состав сервера, являющегося ядром системы информационного взаимодействия предприятия (BizTalk Server, IBM BIS, и т.д.) Связь со службой со-
общений происходит посредством адаптера данных, который преобразовывает данные из формата, специфического для данного приложения, в общий формат данных сервера, построенный на основе XML. Если адаптер данных в составе используемого ПО отсутствует, он может быть разработан сотрудниками предприятия, занимающимися внедрением этого ПО, или взаимодействие со службой обмена сообщениями может быть налажено без использования адаптера данных, поскольку служба обмена сообщениями может быть представлена как веб-сервис. Разработка собственного адаптера данных не сложнее интеграции приложений через API и может быть облегчена наличием в составе сервера интеграции универсальных адаптеров данных, которые после некоторых доработок могут быть использованы в работе с конкретным приложением. Для управления очередью сообщений в состав сервера интеграции входит служба управления потоками данных. Эта служба отвечает не только за доставку данных между приложениями, но и может быть использована для реализации дополнительной бизнес-логики. Таким образом, в случае необходимости можно избежать разработки дополнительного ПО, заменив его стандартными компонентами сервера интеграции.
<^САПР~^> (^^ERP^^
ЗГЕ
ERP
ÜC
и
XML
XML
XML
Служба обмена сообщениями
Служба управления потоками
Рис. 1. Схема организации EAI
Для реализации обмена информацией между предприятиями используется аналогичная по сути схема. Сервер интеграции выступает в роли веб-сервиса, предоставляющего доступ к информационным ресурсам предприятия. Процесс обмена информацией между различными предприятиями также реализован при помощи XML. Поскольку информационные системы различных предприятий различны, то становится необходимым применение возможностей службы управления потоками данных по организации дополнительной бизнес-логики. Происходит выборка информации их информационных источников предприятия (в процессе могут использоваться хранилища данных нескольких приложений сразу), ее обработка, и передача во внешний мир информационного сообщения, отвечающего запросам стороннего предприятия. Аналогично, передаваемая сторонним предприятием информация может дробиться и заноситься в хранилища данных различных приложений.
Заключение
Предложенный метод интеграции систем подготовки производства позволяет интегрировать различные приложения, имеющие различные программные и аппаратные платформы. Метод является масштабируемым и достаточно простым в реализации за счет использования общепринятых и широко распространенных стандартов. Дополнительным преимуществом является использование в процессе интеграции разработан-
ных ведущими производителями программного обеспечения компонентов, что в значительной степени облегчает реализацию интеграции на практике. Минусом такого метода является необходимость внедрения на предприятии еще одного дорогостоящего программного продукта. При выборе решения необходимо учитывать возможности потребности конкретного предприятия.
Литература
1. Куликов Д.Д., Падун Б.С., Яблочников Е.И., Скуратов А.К., Тихонов А.Н. Методы автоматизации ТПП в приборостроении и машиностроении. СПб: СПбГУ ИТМО, 2GG6.
2. Roger Sessions, Janet Van Sickler. Software Fortresses: Modeling Enterprise Architectures. Addison-Wesley Рress, 2GG3.
3. James Wilson, William Harding, Steven Baker, Jim Christensen, Scott Vidican. Microsoft® .NET Server Solutions for the Enterprise. Microsoft Press, 2GG4.
