Современное состояние автоматизации технологического проектирования

   Работа  корпоративных систем управления знаниями (СУЗ), с одной стороны, предполагает получение и интеграцию индивидуальных знаний специалистов, работающих на предприятиях-партнерах, а с другой стороны — формирование и применение метазнаний о совместной генерации и коллективном использовании корпоративных знаний.

   Наиболее  важными требованиями к СУЗ оказываются: гибкость, возможность осуществления семантического поиска, чувствительность к контексту, адаптация к пользователю, прогностичность. Уже сегодня на рынке СУЗ представлены как простые системы, обеспечивающие выполнение отдельных функций управления корпоративными знаниями (например, система совместной фильтрации Grapevine), так и сложные, интегрированные системы (например, Fulcrum — система управления знаниями масштаба предприятия).

   Разделение  ресурсов требует эффективного управления процессами. Общие ресурсы ВП как  MAC складываются из ресурсов его агентов. Для обеспечения доступа партнеров к ресурсам для каждого агента может использоваться локальная объектно-ориентированная концептуальная схема, в которой все ресурсы отображены как объекты и отражены их свойства, связи, ограничения и операции. Затем строится глобальная концептуальная схема всего ВП, которая образуется из локальных схем и дополнительных ресурсов ВП. Подобная концептуальная схема вместе с другой информацией совместного пользования образуют базу метаданных и знаний (Metadata and Knowledge Base).

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

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

   COBRA–технология. Проблема интеграции объектно-ориентированного подхода и распределенных вычислений — одна из ключевых при создании ВП — находится в центре внимания многих коллективов разработчиков, среди которых выделяется мощный международный консорциум Object Management Group (OMG). Этот консорциум занимается разработкой спецификаций и стандартов, позволяющих строить распределенные объектные приложения. Им была предложена архитектура управления объектами ОМА (Object Management Architecture), лежащая в основе стандарта CORBA, которая обеспечивает совместимость и возможность взаимодействия объектов в компьютерной сети, включающей различные аппаратные и программные средства. Основная идея построения данной архитектуры состоит в следующем.

   Решение любой задачи представляется в форме  взаимодействия (физически) распределенных по различным ЭВМ объектов. Для описания предметной области в терминах взаимодействующих объектов служит язык IDL (Interface Definition Language), который представляет собой декларативный объектно-ориентированный язык. Он позволяет строить интерфейсы, не зависящие от языка программирования, используемого для реализации.

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

   Архитектура ОМА состоит из четырех основных компонентов, которые можно разделить  на два класса: системные компоненты и прикладные компоненты. К системным  компонентам относятся: собственно общая архитектура брокера запросов объектов CORBA (Common Object Request Broker Architecture); объектные службы (Object Services). Среди прикладных компонентов выделяются: объекты приложений; универсальные средства. Здесь центральное место занимает брокер запросов объектов ORB. Он охватывает всю коммуникационную инфраструктуру, необходимую для идентификации и размещения объектов, поддержания связей и доставки данных. В частности, брокер запросов взаимодействует с объектными службами, которые отвечают за создание объектов, контроль за доступом и пр. Перечислим главные средства стандарта CORBA:

   - объектный брокер запросов ORB (Object Request Broker);

   - язык определения интерфейсов IDL (Interface Definition Language);

   - объектный адаптер ОА (Object Аdapter);

   - репозиторий интерфейсов IR (Interface Rtpository).

   Роль  CORBA-технологии для ВП заключается в том, что с ее помощью определяется система, которая обеспечивает "прозрачное” взаимодействие между объектами в неоднородной распределенной среде.

   CALS-технологии и стандарт STEP. “Визитной карточкой" ВП в машиностроении является опора на CALS-технологии, предоставляющие необходимый комплект инструментальных средств (ИС), содержащих набор методов, подпрограмм и стандартов представления и передачи производственной и бизнес-информации. Эти ИС позволяют представить любую информацию в единой структуре и формате, облегчая передачу, хранение, поиск разнородных технических данных и знаний, необходимых для проектирования, производства и сопровождения продукции.

   Первоначальное  сокращение CALS означало Computer Aided Acquisition and Logistic Support (автоматизированное приобретение информации и логистическая поддержка), а с начала 90-х годов прежняя аббревиатура стала использоваться для описания понятия Continuous Acquisition and Life Cycle Support (непрерывное приобретение информации и поддержка жизненного цикла). Предвестником века CALS-технологии стали идеи "безбумажной информатики" на основе электронного обмена данными, выдвинутые еще в самом начале 70-х годов академиком В. М. Глушковым. Через полтора десятка лет многие идеи безбумажной информатики нашли свое воплощение в русле глобальной стратегии CALS, которая стала развиваться с 1985 г. по линии Министерства обороны США (Departement of Defense) и оборонных отраслей промышленности с целью эффективной организации и интеграции обмена и управления данными, требующимися при проектировании, производстве и логистической поддержке систем вооружений. В дальнейшем, CALS-технология стала успешно применяться и в гражданских отраслях, позволив повысить эффективность использования компьютерных ресурсов предприятий на всех стадиях жизненного цикла разрабатываемой продукции, а также значительно сократить документацию на бумажном носителе. В самые последние годы стала также применяться новая аббревиатура CALS/CE, прямо указывающая на интеграцию CALS-технологии и методов совмещенной разработки (Concurrent Engineering).

   В целом, CALS как глобальная стратегия  обмена и управления данными в  рамках ВП позволяет:

   - уменьшить количество документов на бумажном носителе, циркулирующих в ВП;

   - повысить согласованность данных, получаемых различными агентами;

   - уменьшить время реакции ВП  на неожиданные изменения конъюнктуры  рынка;

    - лучше интегрировать проектирование и производство;

   - уменьшить ошибки в процессах кооперативного проектирования и распределенного производства.

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

   Информационные CALS-стандарты включают: ISO 10303 STEP (стандарт обмена данными об изделии); ISO 13584 P_LIB (библиотека компонентов изделий); ISO 15531 MANDATE (описание производственного процесса). Здесь набор стандартов ISO 10303 STEP занимает исключительное положение. Без него трудно реализовать главную идею CALS-технологии, согласно которой у разработчиков (при условии разрешенного доступа) может иметься вся информация о продукте, соответствующая всем стадиям его жизненного цикла. Цель создания серии стандартов STEP состоит в реализации единого языка описания информации о различных моделях продукта в течение всего его жизненного цикла, языка, не зависящего от используемого программного обеспечения. Иными словами, применение STEP охватывает все виды производимой и промежуточной машиностроительной продукции (детали, сборочные единицы, агрегаты, изделия) на всех стадиях их жизненного цикла (проектирование, конструирование, технологическая подготовка производства, производство, эксплуатация, утилизация), включая все соответствующие специальности (автоматика, механика, информатика, электроника и пр.).

   Стандарт  ISO 10303 STEP как общий "словарь" предметной области позволяет агентам, участвующим в совместном проекте, строить единые модели продукта (изделия) и производственной среды. Различные агенты используют различные подмножества общей модели изделия в зависимости от этапа жизненного цикла изделия (ЖЦИ), который они обеспечивают, и функций, которые выполняют. Прохождение информации между ними предполагает пересечение моделей взаимодействующих агентов.

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

   Вся проектная информация об изделии  может помещаться в репозиторий или хранилище данных STEP Warehouse. Он предназначен для интеграции производственных данных, поступающих из различных источников и хранения информации о продукте (изделии) на протяжении всего его жизненного цикла. Таким образом, STEP-репозиторий содержит различные модели продукции. Предполагается, что эти модели продукции могут храниться в виде данных STEP, соответствующих прежде всего протоколу АР203, а также другим протоколам применения.

   Чтобы реализовать механизмы обмена данными  на основе STEP, в стандарт включено описание символьного обменного файла, а для реализации доступа к данным, хранящимся в репозитории, в него включено описание интерфейса данных SDAI (Standard Data Access Interface).

   Каковы  же основные уровни реализации STEP и этапы внедрения CALS-технологий в практику ВП? На наш взгляд, можно выделить четыре уровня развития STEP: 1) уровень обмена символьными файлами; 2) уровень работы с данными посредством стандартного интерфейса; 3) уровень работы с базами данных; 4) уровень работы с базами знаний. Соответственно, основные этапы внедрения CALS-средств таковы.

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

   - Интеграция, связанная с разработкой интегрированных баз данных, объединяющих стандартизованную информацию. Создание централизованных структурированных хранилищ данных (Data Warehouses). Концепция хранилища данных уже нашла широкое применение, и здесь речь идет о том, чтобы строить подобные хранилища в соответствии с информационными CALS-стандартами, что обеспечит их полную совместимость.

   - Создание и внедрение комплексных систем автоматизации и управления предприятием, построенных в соответствии со стандартом MANDATE. Такие системы сейчас также широко применяются (например, BAAN, R3), но в контексте развития ВП нужны новые версии подобных средств, построенные в соответствии со стандартами CALS и использующие их в своей работе.

   При создании ВП машиностроения необходимо расширение стандарта STEP для обеспечения следующих возможностей:

   - совмещенного и кооперативного проектирования, коллективной генерации моделей на основе разделенных знаний;

   - взаимодействия  различных приложений, когда они должны работать с общей базой данных в разделенном режиме;

   - совместной разработки документации, когда требуется объединить отдельные части документов, разработанные различными специалистами, в один документ.