Прикладные протоколы в STEP
Что называют прикладным протоколом (протоколом применения) в STEP?
  1. онтологию приложения, представленную на языке Express;
  2. совокупность правил обмена данными между автоматизированными системами;
  3. прикладную базу данных (информационную модель приложения);
  4. имитационную модель приложения.
Ответ
  1. Правильно
  2. Неправильно
  3. Неправильно
  4. Неправильно
При неправильных ответах см. прикладной протокол.


Интерактивные электронные технические руководства
Отметьте в списке требования, предъявляемые к интерактивным электронным техническим руководствам (ИЭТР) в CALS-технологиях:
  1. ИЭТР должно быть представлено на языке Express;
  2. ИЭТР должно быть представлено на языке SGML;
  3. ИЭТР должно представлять собой имитационную модель изделия.
Ответ
  1. Неправильно
  2. Правильно
  3. Неправильно
При неправильных ответах см. ИЭТР.


Этапы жизненного цикла изделий и промышленные автоматизированные системы
Жизненный цикл изделий (ЖЦИ) включает ряд этапов, начиная от зарождения идеи нового продукта до его утилизации по окончании срока использования. К ним относятся этапы маркетиноговых исследований, проектирования, технологической подготовки производства (ТПП), собственно производства, послепродажного обслуживания и эксплуатации продукции, утилизации.
На всех этапах жизненного цикла имеются свои целевые установки. При этом участники жизненного цикла стремятся достичь поставленных целей с максимальной эффективностью. На этапах проектирования, ТПП и производства нужно обеспечить выполнение требований, предъявляемых к производимому продукту, при заданной степени надежности изделия и минимизации материальных и временных затрат, что необходимо для достижения успеха в конкурентной борьбе в условиях рыночной экономики. Понятие эффективности охватывает не только снижение себестоимости продукции и сокращение сроков проектирования и производства, но и обеспечение удобства освоения и снижения затрат на будущую эксплуатацию изделий. Особую важность требования удобства эксплуатации имеют для сложной техники, например, в таких отраслях, как авиа- или автомобилестроение.
Достижение поставленных целей на современных предприятиях, выпускакющих сложные технические изделия, оказывается невозможным без широкого использования автоматизированных систем (АС), основанных на применении компьютеров и предназначенных для создания, переработки и использования всей необходимой информации о свойствах изделий и сопровождающих процессов. Специфика задач, решаемых на различных этапах жизненного цикла изделий, обусловливает разнообразие применяемых АС.
На рис. 1 указаны основные типы АС с их привязкой к тем или иным этапам жизненного цикла изделий.
Рис. 1. Этапы жизненного цикла промышленной продукции и используемые автоматизированные системы
Рассмотрим содержание основных этапов ЖЦИ для изделий машиностроения.
Цель маркетинговых исследований — анализ состояния рынка, прогноз спроса на планируемые изделия и развития их технических характеристик.
На этапе проектирования выполяются проектные процедуры — формирование принципиального решения, разработка геометрических моделей и чертежей, расчеты, моделирование процессов, оптимизация и т.п. Этап проектирования включает все необходимые стадии, начиная с внешнего проектирования, выработки концепции (облика) изделия и кончая испытаниями пробного образца или партии изделий. Внешнее проектирование обычно включает разработку технического и коммерческого предложений и формирование технического задания (ТЗ) на основе результатов маркетиноговых исследований и/или требований, предъявленных заказчиком.
На этапе подготовки производства разрабатываются маршрутная и операционная технологии изготовления деталей, реализуемые в программах для станков ЧПУ; технология сборки и монтажа изделий; технология контроля и испытаний.
На этапе производства осуществляются: календарное и оперативное планирование; приобретение материалов и комплектующих с их входным контролем; механообработки и другие требуемые виды обработки; контроль результатов обработки; сборка; испытания и итоговый контроль.
На постпроизводственных этапах выполняются консервация, упаковка, транспортировка; монтаж у потребителя; эксплуатация, обслуживание, ремонт; утилизация.
Автоматизация проектирования осуществляется САПР. В САПР машиностроительных отраслей промышленности принято выделять системы функционального, конструкторского и технологического проектирования. Первые из них называют системами расчетов и инженерного анализа или системами CAE (Computer Aided Engineering). Системы конструкторского проектирования называют системами CAD (Computer Aided Design). Проектирование технологических процессов выполняется в автоматизированных системах технологической подготовки производства (АСТПП), входящих как составная часть в системы CAM (Computer Aided Manufacturing).
Для решения проблем совместного функционирования компонентов САПР различного назначения, координации работы систем CAE/CAD/CAM, управления проектными данными и проектированием разрабатываются системы, получившие название систем управления проектными данными PDM (Product Data Management). Системы PDM либо входят в состав модулей конкретной САПР, либо имеют самостоятельное значение и могут работать совместно с разными САПР.
На большинстве этапов жизненного цикла, начиная с определения предприятий-поставщиков исходных материалов и компонентов и кончая реализацией продукции, требуются услуги системы управления цепочками поставок — Supply Chain Management (SCM). Цепь поставок обычно определяют как совокупность стадий увеличения добавленной стоимости продукции при ее движении от компаний-поставщиков к компаниям-потребителям. Управление цепью поставок подразумавет продвижение материального потока с минимальными издержками. При планировании производства система SCM управляет стратегией позиционирования продукции. Если время производственного цикла меньше времени ожидания заказчика на получение готовой продукции, то можно применять стратегию "изготовление на заказ". Иначе приходится использовать стратегию "изготовление на склад". При этом во время производственного цикла должно входить время на размещение и исполнение заказов на необходимые материалы и комплектующие на предприятиях-поставщиках.
В последнее время усилия многих компаний, производящих программно-аппаратные средства автоматизированных систем, направлены на создание систем электронного бизнеса (E-commerce). Задачи, решаемые системами E-commerce, сводятся не только к организации на сайтах Internet витрин товаров и услуг. Они объединяют в едином информационном пространстве запросы заказчиков и данные о возможностях множества организаций, специализирующихся на предоставлении различных услуг и выполнении тех или иных процедур и операций по проектированию, изготовлению, поставкам заказанных изделий. Проектирование непосредственно под заказ позволяет добиться наилучших параметров создаваемой продукции, а оптимальный выбор исполнителей и цепочек поставок ведет к минимизации времени и стоимости выполнения заказа. Координация работы многих предприятий-партнеров с использованием технологий Intrenet возлагается на системы E-commepce, называемые системами управления данными в интегрированном информационном пространстве CPC (Collaborative Product Commerce)
Управление в промышленности, как и в любых сложных системах, имеет иерархическую структуру. В общей структуре управления выделяют несколько иерархических уровней, показанных на рис. 2. Автоматизация управления на различных уровнях реализуется с помощью автоматизированных систем управления (АСУ).
Рис. 2. Общая структура управления
Информационная поддержка этапа производства продукции осуществляется автоматизированными системами управления предприятием (АСУП) и автоматизированными системами управления технологическими процессами (АСУТП).
К АСУП относятся системы планирования и управления предприятием ERP (Enterprise Resource Planning), планирования производства и требований к материалам MRP-2 (Manufacturing Requirement Planning) и упомянутые выше системы SCM. Наиболее развитые системы ERP выполняют различные бизнес-функции, связанные с планированием производства, закупками, сбытом продукции, анализом перспектив маркетинга, управлением финансами, персоналом, складским хозяйством, учетом основных фондов и т.п. Системы MRP-2 ориентированы, главным образом, на бизнес-функции, непосредственно связанные с производством. В некоторых случаях системы SCM и MRP-2 входят как подсистемы в ERP, в последнее время их чаще рассматривают как самостоятельные системы.
Промежуточное положение между АСУП и АСУТП занимает производственная исполнительная система MES (Manufacturing Execution Systems), предназначенная для решения оперативных задач управления проектированием, производством и маркетингом.
В состав АСУТП входит система SCADA (Supervisory Control and Data Acquisition), выполняющая диспетчерские функции (сбор и обработка данных о состоянии оборудования и технологических процессов) и помогающая разрабатывать ПО для встроенного оборудования. Для непосредственного программного управления технологическим оборудованием используют системы CNC (Computer Numerical Control) на базе контроллеров (специализированных компьютеров, называемых промышленными), которые встроены в технологическое оборудование с числовым программным управлением (ЧПУ). Системы CNC называют также встроенными компьютерными системами.
Система CRM используется на этапах маркетиноговых исследований и реализации продукции, с ее помощью выполняются функции управления отношениями с заказчиками и покупателями, проводится анализ рыночной ситуации, определяются перспективы спроса на планируемые изделия.
Функции обучения обслуживающего персонала выполняют интерактивные электронные технические руководства IETM (Interactive Electronic Technical Manuals). С их помощью выполняются диагностические операции, поиск отказавших компонентов, заказ дополнительных запасных деталей и некоторые другие операции на этапе эксплуатации систем.
Управление данными в едином информационном пространстве на протяжении всех этапов жизненного цикла изделий возлагается на систему PLM (Product Lifecycle Management). Под PLM понимают процесс управления информацией об изделии на протяжении всего его жизненного цикла. Отметим, что понятие PLM-система трактуется двояко: либо как интегрированная совокупность автоматизированных систем CAE/CAD/CAM/PDM и ERP/CRM/SCM, либо как совокупность только средств информационной поддержки изделия и интегрирования автоматизированных систем предприятия, что практически совпадает с определением понятия CALS. Характерная особенность PLM — возможность поддержки взаимодействия различных автоматизированных систем многих предприятий, т.е. технологии PLM являются основой, интегрирующей информационное пространство, в котором функционируют САПР, ERP, PDM, SCM, CRM и другие автоматизированные системы многих предприятий.


Язык Express (пример 1)
Опишите на языке Express чертеж детали, представленный на рис. 1 (без указания размеров).
Рис. 1.
Ответ
Модель на языке Express:
SCHEMA detail;

ENTITY line;
P1,P2: point;
END_ENTITY;

ENTITY circle;
P1: point;
R: REAL;
END_ENTITY;

ENTITY d_line;
P1,P2: point;
END_ENTITY;

ENTITY point;
X,Y: REAL;
END_ENTITY;

END_SCHEMA;


Основные положения и принципы CALS
Исторически по ряду объективных и субъективных причин многие подсистемы САПР и АСУ создавались как автономные системы, не ориентированные на взаимодействие с другими АС. При этом каждая из АС успешно решает определенный круг задач отдельного этапа проектирования изделий или помогает принимать решения по отдельным бизнес-процедурам этапов ЖЦИ. Но задача взаимодействия АС разных производителей и их подсистем зачастую не ставилась и не рассматривалась. Языки и форматы представления данных в разных программах не были согласованными, например, данные конструкторского проектирования не отвечали требованиям к входным данным для программ проектирования технологических процессов.
Негативные последствия несогласованности лингвистического и информационного обеспечений разных АС наиболее выпукло проявляются при росте сложности систем, в проектировании которых задействовано несколько предприятий. Показательным примером является попытка в 80-е годы создания в США системы стратегической оборонной инициативы. Стало очевидным, что без информационного взаимодействия разных АС и их подсистем эффективность автоматизации оказывается низкой, а создание многих современных сложных технических изделий – неразрешимой проблемой.
Таким образом, дальнейший прогресс в области техники и промышленных технологий оказался в зависимости от решения проблем интеграции АС путем создания единого информационного пространства управления, проектирования, производства и эксплуатации изделий. Ответом на возникшие проблемы стало создание методологии компьютерного сопровождения и информационной поддержки промышленных изделий на всех этапах их жизненного цикла. Эта методология получила название CALS.
К основным целям CALS относится прежде всего создание принципиальной возможности дальнейшего технического прогресса по пути разработки и производства усложняющихся промышленных изделий. Но CALS позволяет повысить эффективность разработки и изготовления также большинства традиционных изделий, что выражается в повышении качества, в сокращении материальных и временных затрат как на проектирование и производство, так и на эксплуатацию изделий.
Первоначально CALS создавалась как совокупность методов и средств решения логистических задач и аббревиатура CALS расшифровывалась как Computer Aided Logistics Systems. В дальнейшем сфера применения CALS расширилась и охватила все стороны информационной поддержки промышленных изделий, включая проектирование, управление предприятиями и технологическими процессами. Соответственно CALS получила новую интерпретацию и стала рассматриваться как Continuous Acquisition and Lifecycle Support. В качестве русскоязычного эквивалента CALS принято сокращение ИПИ – информационная поддержка изделий.
Что же такое CALS в современном понимании?
Существует и используется несколько толкований.
В широком смысле слова CALS = это методология создания единого информационного пространства промышленной продукции, обеспечивающего взаимодействие всех промышленных автоматизированных систем. В этом смысле предметом CALS являются методы и средства как взаимодействия разных АС и их подсистем, так и сами АС с учетом всех видов их обеспечения. Практически синонимом CALS в этом смысле становится термин PLM (Product Lifecycle Management), широко используемый в последнее время ведущими производителями АС.
В узком смысле слова CALS – это технология интеграции различных АС со своими лингвистическим, информационным, программным, математическим, методическим, техническим и организационным видами обеспечения.
К лингвистическому обеспечению CALS относятся языки и форматы данных о промышленных изделиях и процессах, используемые для представления и обмена информацией между АС и их подсистемами на различных этапах ЖЦИ.
Информационное обеспечение составляют базы данных, включающие сведения о промышленных изделиях, используемые разными системами в процессе проектирования, производства, эксплуатации и утилизации продукции. В состав информационного обеспечения входят также серии международных и национальных CALS стандартов и спецификаций.
Программное обеспечение CALS представлено программными комплексами, предназначенными для поддержки единого информационного пространства этапов ЖЦИ. Это прежде всего системы управления документами и документооборотом, системы PDM, средства разработки интерактивных электронных технических руководств и некоторые другие.
Математическое обеспечение CALS включает методы и алгоритмы создания и использования моделей взаимодействия различных систем в CALS-технологиях. Среди этих методов, в первую очередь, следует назвать методы имитационного моделирования сложных систем, методы планирования процессов и распределения ресурсов.
Методическое обеспечение CALS представлено методиками выполнения таких процессов, как параллельное (совмещенное) проектирование и производство, структурирование сложных объектов, их функциональное и информационное моделирование, объектно-ориентированное проектирование, создание онтологий приложений.
К техническому обеспечению CALS относят аппаратные средства получения, хранения, обработки, визуализации данных при информационном сопровождении изделий. Взаимодействие разных частей виртуальных предприятий и систем, поддерживающих разные этапы ЖЦИ, происходит через линии передачи данных и сетевое коммутирующее оборудование. При этом широко используются возможности Internet и Web-технологий. Однако используемые технические средства не являются специфическими для CALS.
Организационное обеспечение CALS представлено различного рода документами, совокупностью соглашений и инструкций, регламентирующих роли и обязанности участников жизненного цикла промышленных изделий.
При реализации целей и задач CALS необходимо соблюдать следующие основные принципы:
• информационная поддержка всех этапов ЖЦИ;
• единство представления и интерпретации данных в процессах информационного обмена между АС и их подсистемами, что обусловливает разработку онтологий приложений и соответствующих языков представления данных;
• доступность информации для всех участников ЖЦИ в любое время и в любом месте, что обусловливает применение современных телекоммуникационных технологий;
• унификация и стандартизация средств взаимодействия АС и их подсистем;
• поддержка процедур совмещенного (параллельного) проектирования изделий.


Обменный файл
Для детали, чертеж которой представлен на рис. 1, и ее схемы на языке Express разработать обменный файл в соответствии с ISO 10303-21.
Рис. 1. Чертеж
Схема модели:
SCHEMA detail;
ENTITY line;
P1,P2: point;
END_ENTITY;
ENTITY circle;
P1: point;
R: REAL;
END_ENTITY;
ENTITY d_line;
P1,P2: point;
END_ENTITY;
ENTITY point;
X,Y: REAL;
END_ENTITY;
END_SCHEMA;
Ответ
Обменный файл:
HEADER
 FILE DESCRIPTION (('чертеж'),'1');
 FILE NAME ('fig1','02.04.04',('Иванов'));
 FILE SCHEMA(('detail'));
ENDSEC;
DATA
#1 = point(0,0);
#2 = point(30.,0);
#3 = point(0,16.);
#4 = point(30.,16.);
#5 = point(18.,9.);
#6 = point(40.,0);
#7 = point(48.,0);
#8 = point(40.,16.);
#9 = point(48.,16.);
#6 = point(40.,0);
#7 = point(48.,0);
#8 = point(40.,16.);
#9 = point(48.,16.);
#10 = point(40.,4.);
#11 = point(48.,4.);
#12 = point(40.,14.);
#13 = point(48.,14.);
#14 = line(#1,#2);
#15 = line(#1,#3);
#16 = line(#2,#4);
#17 = line(#3,#4);
#18 = circle(#5,10.);
#19 = line(#6,#7);
#20 = line(#6,#8);
#21 = line(#7,#9);
#22 = line(#8,#9);
#23 = d_line(#10,#11);
#24 = d_line(#12,#13);
ENDSEC;


PDM — управление проектными данными
Системы автоматизированного проектирования относятся к числу наиболее сложных и наукоемких автоматизированных систем. Наряду с выполнением собственно проектных процедур необходимо автоматизировать также управление проектированием, поскольку сам процесс проектирования становится все более сложным и зачастую приобретает распределенный характер. На крупных и средних предприятиях заметна тенденция к интеграции САПР с АСУП и системами документооборота. Для управления столь сложными интегрированными системами в их составе имеется специальное ПО — системная среда САПР или АС, называемая в настоящее время системой управления проектными данными или системой PDM (Product Data management). Системы более общего характера, связанные с управлением данными на всех этапах жизненного цикла изделий и интеграцией различных промышленных автоматизированных систем, получили название систем управления жизненным циклом изделий или систем информационной поддержки изделий PLM (Product Lifecycle Management).
История систем управления проектными данными непосредственно связана с развитием систем автоматизированного проектирования. Появление системных сред в САПР ознаменовало переход от использования отдельных не связанных друг с другом программ, решающих частные проектные задачи, к применению интегрированной совокупности таких программ.
Интегрирующим компонентом в 70-е гг. стала единая БД САПР. Однако попытки использовать имевшиеся в то время СУБД не приводили к удовлетворительным результатам в силу разнообразия типов проектных данных, распределенного и параллельного характера процессов проектирования, с одной стороны, и недостаточной развитости баз данных, с другой стороны.
Специализированные СУБД, ориентированные на САПР, были созданы в 80-е годы. Однако они не учитывали или в недостаточной степени удовлетворяли требованиям обеспечения целостности данных, управления потоками проектных работ, многоаспектного доступа пользователей к данным.
И лишь на рубеже 80-90 гг. появились системы управления проектными данными, названные в то время Framework или системными средами, сначала в САПР электронной промышленности, а позднее и в САПР машиностроения, где они и получили наименование PDM.
На протяжении 90-х годов роль системных сред неуклонно повышалась. Во-первых, из-за роста сложности проектируемых объектов и необходимости сокращать сроки проектирования. Во-вторых, из-за необходимости интеграции систем проектирования с системами управления предприятием и технологическими процессами. Благодаря развитию Internet, Web- и CALS-технологий такая интеграция стала возможной в глобальном масштабе.
Современные системы управления проектными данными называют PDM. Они предназначены для информационного обеспечения проектирования и выполняют следующие основные функции:
  • хранение проектных данных и доступ к ним, в том числе ведение распределенных архивов документов, их поиск, редактирование, маршрутизация, создание спецификаций;
  • структурирование и визуализпация данных;
  • управление конфигурацией изделия, т.е. ведение версий проекта, управление внесением изменений;
  • управление проектированием (проектами);
  • защита информации;
  • интеграция данных (поддержка типовых форматов, конвертирование данных).
Основной компонент систем PDM — банк данных (БнД). Он состоит из системы управления базами данных и баз данных (БД). Межпрограммный интерфейс в значительной мере реализуется через информационный обмен с помощью банка данных. PDM отличает легкость доступа к иерархически организованным данным, обслуживание запросов, выдача ответов не только в текстовой, но и в графической форме, привязанной к конструкции изделия. Поскольку взаимодействие внутри группы проектировщиков в основном осуществляется через обмен данными, то в системе PDM часто совмещают функции управления данными и управления параллельным проектированием.
К важнейшим функциям PDM относятся управление проектами и управление конфигураций изделий.
Рассмотрим остальные функции PDM.
В информационных моделях приложений фигурируют сущности (типы данных) и связи между ними. Установление сущностей, их атрибутов, связей и атрибутов связей означает структурирование проектных данных. Структура изделий обычно может быть представлена иерархически, в виде дерева. Иерархическая форма удобна при внесении и отслеживании изменений в модели, например, при добавлении и удалении сущностей, изменениях их атрибутов, введении новых связей. Поэтому одной из первоочередных функций PDM является поддержка интерактивной работы пользователя при создании моделей изделий (процессов), структурирование описаний проектируемых объектов, предъявление пользователю этой иерархической структуры вместе с возможностями навигации по дереву и получению нужной информации по каждой указанной пользователем структурной компоненте.
Например, в системе PDM STEP Suite элементы дерева, представляющего структуру изделия, могут соответствовать сборочным узлам, агрегатам, блокам, отдельным деталям. Навигация по дереву позволяет просматривать относящиеся к структурным единицам документы, геометрические модели, чертежи и другие атрибуты.
В системе BaanPDM основными типами данных являются документы и изделия. Экземпляры сущностей идентифицируются и описываются с помощью набора атрибутов, среди которых имеется уникальный индентификатор (ключ) объекта и ряд дополнительных атрибутов, например, тип документа, автор, количество входящих в документ страниц. Стандартные функции поддержки объекта включают возможность добавлять объекты (при этом добавляется уникальный идентификатор и другие атрибуты), модифицировать атрибуты объекта и удалять объекты.
В системе PDM, разработанной в свое время фирмой Cadence для своей САПР, была предусмотрена иерархическая организация проектных данных, описывающих проектируемые СБИС (сверхбольшие интегральные схемы), с выделением уровней библиотек, категорий, ячеек, видов. Ячейка — базовый объект, который может иметь несколько различных представлений (видов). Ячейки объединяются в родственные группы — категории, а категории — в библиотеки. Разработчик с помощью системной среды имеет доступ к проектным данным, может создавать свои библиотеки, ячейки, виды.
Интерфейс с пользователем поддерживается визуализацией данных проекта одновременно в нескольких окнах. Для визуализации данных разных аспектов в PDM имеется ряд браузеров. Типичные изображения структуры изделия, создаваемые браузерами, представляются иерархическим списком или графически в виде дерева изделия или его фрагментов. В других окнах могут быть помещены различные виды, такие как 2D чертеж или 3D изображение; описания моделей; принципиальные схемы; атрибуты объекта (исполнитель, номер версии, дата утверждения и т.п.). Иногда для визуализации и редактирования данных в PDM конкретной фирмы привлекаются браузеры и редакторы других изготовителей.
Для примера на рис. 1 показан небольшой фрагмент дерева изделия. Обычно на экране дисплея рядом с названием компонента структуры высвечивается также присвоенный ему код. Выбор любого компонента (узла дерева) позволяет, во-первых, получить в появляющихся окнах требуемую информацию о компоненте. во-вторых, для компонента, являющегося сборкой, раскрыть следующий по иерархии фрагмент, в котором данный компонент будет представлен уже корневым узлом.
Рис. 1. Фрагмент дерева изделия
Целостность данных поддерживается в процессе управления конфигурацией проекта, а также тем, что нельзя одновременно изменять один и тот же объект разным разработчикам, каждый из них должен работать со своей рабочей версией. Другими словами, необходимо обеспечение синхронизации изменения данных, разделяемых многими пользователями.
Для этого выполняется авторизация пользователей и разрабатываются средства ведения многих версий проекта. Во-первых, пользователи подразделяются на классы (администрация системы, руководство проектом и частями проекта, группы исполнителей-проектировщиков) и для каждого класса вводят определенные ограничения, связанные с доступом к разделяемым данным; во-вторых, доступ регламентируется по типам разделяемых данных. Данным могут присваиваться различные значения статуса, например, "правильно", "необходимо перевычисление", "утверждено в качестве окончательного решения" и т.п. Собственно синхронизация выполняется с помощью механизмов типа рандеву или семафоров, рассматриваемых в пособиях по параллельным вычислениям.
В системе BaanPDM каждому пользователю в зависимости от его роли назначается уровень прав доступа — один из восьми возможных. На низшем уровне пользователь может только просматривать данные. На высшем уровне, присваиваемом старшему администратору, допускаются любые модификации данных любого проекта и архивов. В функции лица, являющегося системным администратором, входят упорядочение данных с их распределением по дискам, контроль за правами доступа пользователей, связь с внешними системами (управление импортом-экспортом данных) и др.
Типичная схема разделения рабочего пространства между параллельно работающими пользователями показана на рис. 2.
Рис. 2. Информационные связи разработчиков с зонами базы данных
Следующими важными функциями PDM являются управление документами и документооборотом. Проектная документация характеризуется разноплановостью и большими объемами. В процессе проектирования используют чертежи, конструкторские спецификации или BOM, пояснительные записки, ведомости применяемости изделий, различного рода отчеты и др. Кроме того, в интегрированных автоматизированных системах проектирования и управления в документооборот входит большое число документов, связанных с процедурами маркетинга, снабжения, планирования, администрирования и т.п. .
Важно обеспечить автоматический учет влияния и распространения вносимых в проект изменений на другие части проектной документации.
Для подготовки, хранения и сопровождения необходимых документов, в том числе чертежей и схем, в PDM включают специализированные системы управления документами и системы управления документооборотом или адаптируют полнофункциональные системы делопроизводства, разработанные независимо от конкретных PDM. Часто используют программы Lotus Notes и Lotus Domino компании Lotus Development. Возможности управления чертежно-конструкторской документацией, подготовленной в AutoCAD и Microstation, имеются в продуктах DOCS Open (компания Hummingbird), CADLink, входящем в систему управления документами и бизнес-процессами Documentum, Search (белорусская компания Интермех) и ряде других.
В системе Search осуществляются хранение и поиск данных, доступ к ним, документооборот, разработка спецификаций, внесение изменений и др. Для этого имеются редактор извещений об изменениях в проекте, средства обеспечения групповой работы над проектом, модуль доступа к документам, расположенным на других узлах сети. Редактирование и просмотр выполянются с помощью внешних редакторов.
Следует отметить, что параллельное проектирование (совмещенное проектирование), интеграция автоматизированных систем проектирования и управления на современных предприятиях возможны только в распределенной среде. Распределенные хранение и обработка информации в большинстве случаев осуществляются на базе применения технологий SOAP, CORBA или DCOM, языков Java и XML. Данные проекта при этом находятся в хранилищах данных, т.е. в нескольких базах распределенного банка данных. Находят применение трехзвенные распределенные системы с уровнями сервер баз данных — сервер приложений — клиенты. Принимаются меры по защите информации, типичные для корпоративных информационных систем. Разработаны рекомендации по внедрению операций с электронными цифровыми подписями.
Интеграция данных на ранних этапах развития PDM связывалась только с организацией сквозного проектирования изделий в рамках конкретной САПР. В настоящее время в связи с развитием CALS-технологий основным содержанием проблемы интеграции стало обеспечение интерфейса САПР с другими автоматизированными системами. Проблема решается с помощью поддержки типовых форматов, например, путем конвертирования данных из общепринятых форматов во внутренние представления конкретных САПР.
В CALS-технологиях взаимодействие систем основано на стандартах STEP, поэтому в ряде PDM имеются конверторы из предложенного в STEP языка Express. В STEP введен прикладной протокол AP208, представляющий собой информационную модель, относящуюся к управлению процессами изменений в жизненном цикле изделий. В соответствии с AP208 внесению изменений предшествуют идентификация фактов (недостатков), требующих внесения изменений, установление вызвавших их причин и определение лиц, вносящих изменения. Среди других форматов данных обычно используются IGES, DXF, VRML, SAL, EDIF, текстовые и 2D графические форматы и др.
Адаптация САПР к условиям конкретных предприятий может быть осуществлена с помощью языков расширения. Язык расширения — язык программирования, позволяющий адаптировать и настраивать системную среду на выполнение новых проектов. Язык расширения должен обеспечивать доступ к различным компонентам системной среды, объединять возможности базового языка программирования и командного языка, включать средства процедурного программирования. Для большинства языков расширения базовыми являются Lisp или C.
Примерами таких языков могут служить язык Skill из Design Framework-2 фирмы Cadence или язык CCL (CASE Comment Language) фирмы Matra Datavision, являющиеся Lisp-подобными, или язык AMPLE из PDM Falcon Framework фирмы Mentor Graphics, базирующийся на языках C и ПАСКАЛЬ.


Язык Express (пример 2)
Создайте на языке Express модель и обменный файл для электронной схемы рис. 1.
Рис. 1. Электронная схема
Ответ
Схема модели:
SCHEMA circuit;
ENTITY transistor;
TypeT:STRING;
E,B,C: node;
END_ENTITY;
ENTITY resistor;
P1,P2: node;
nominal: REAL;
END_ENTITY;
ENTITY terminal;
role: STRING;
term: node;
END_ENTITY;
TYPE node=INTEGER;
END_TYPE;
END_SCHEMA;
Обменный файл:
HEADER
FILE DESCRIPTION (('cascade'),'1');
FILE NAME ('ampl','02.04.04',('Иванов'));
FILE SCHEMA(('circuit'));
ENDSEC;
DATA
#1 = resistor(2,4,40.0);
#2 = resistor(3,4,1.3);
#3 = transistor('Tp1',1,2,3)
#4 = terminal('Input',2);
#5 = terminal('Output',3);
#6 = terminal('Power',4);
ENDSEC;


Интегрированная логистическая поддержка
К числу CALS-технологий относят технологии интегрированной логистической поддержки изделий (ИЛП). Под ИЛР понимают подход к комплексному решению логистических задач в процессе создания и эксплуатации изделий и прежде всего обеспечение их эффективной эксплуатации на основе создания необходимых средств обслуживания изделий, в том числе документации и баз данных, предназначенных для обучения персонала, диагностики изделий, их ремонта и т.п.
Появление концепции интегрированной логистической поддержки (ИЛП) изделий и интегрированных логистических систем обусловлено стремлением максимально повысить эффективность эксплуатации сложной техники. Под ИЛП понимают комплекс мер и процедур, направленных на снижение общих затрат на всех этапах жизненного цикла изделий (ЖЦИ), прежде всего на этапе эксплуатации.
В понятие ИЛП входят:
  • исследование состояния рынка и прогнозирование перспектив сбыта изделий, планируемых к производству;
  • определение инфраструктуры системы обслуживания изделий в период эксплуатации, в том числе планирование процедур материально-технического обеспечения, диагностики состояния изделий, ремонта и т.п.;
  • учет требований ремонтопригодности при проектировании изделий, разработка средств обслуживания сложной техники параллельно с разработкой самого изделия;
  • расчет надежности и длительности безотказной работы изделий,
  • расчет затрат на производство и эксплуатацию изделий;
  • определение состава и необходимого объема запасных частей,
  • обучение обслуживающего персонала;
  • поддержка связей между производителем и потребителем путем доступа потребителя к интегрированной базе данных изделия с целью упрощения диагностики состояния и ремонта изделий, а также получения изготовителем данных о неисправностях и отказах с целью принятия мер по повышению надежности изделий;
  • классификация и кодификация изделий и материалов, необходимые для упрощения поиска нужных данных в справочниках и БД, исключения дублирования проектов, ускорения составления заявок на поставки комплектующих и т.п.;
  • разработка и сопровождение электронной эксплуатационной и ремонтной документации;
  • традиционные логистические процедуры, такие как упаковка, складирование, транспортировка изделий.
Уже на стадии проектирования прогнозируются затраты и определяются ресурсы, необходимые для поддержки изделия в нужном состоянии, создается БД ИЛП (рис. 1), предназначенная для информационного обслуживания всех участников жизненного цикла изделия, разрабатывается электронная техническая документация, используемая при закупке, поставке, вводе в действие, при эксплуатации, сервисном обслуживании и ремонте изделия, планируются потребности в средствах технического обслуживания. В системах ИЛП контролируются процессы поставки изделий, формирования и исполнения заявок, в процессе эксплуатации изделия база данных ИЛП является доступной обслуживающему персоналу. Следует отметить, что ИЛП тесно связана с обеспечением управления качеством продукции в соответствии со стандартами серии ISO 9000.
Рис. 1. Основные процедуры и потоки в системе ИЛП
До недавнего времени процесс ИЛП регламентировался стандартом министерства обороны США MIL-STD-1388. В настоящее время в качестве основного стандарта ИЛП де-факто признан стандарт Великобритании DEF STAN 00-60.
Большая часть задач ИЛП может быть разделена на группы анализа логистической поддержки (АЛП), технического обслуживания и ремонта (ТОиР), материально-технического обеспечения (МТО), управления заказами, разработки технической документации, а также указанные на рис. 1 группы проектирования средств обслуживания, разработки документации и обучения персонала.


Анализ логистической поддержки
Анализ логистической поддержки (АЛП) — группа важных задач, с выполнения которых начинается интегрированная логистическая поддержка (ИЛП). Под АЛП понимают формализованную технологию всестороннего исследования как самого изделия, так и вариантов системы его эксплуатации и поддержки с целью сокращения затрат на постпроизводственных стадиях жизненного цикла при обеспечении требуемого уровня готовности изделия
На ранних стадиях разработки (техническое предложение, эскизный проект) основное внимание должно быть сосредоточено на оценке конструкции разрабатываемого изделия с точки зрения поддерживаемости и формировании требований к изделию и системе поддержки.
На стадии подготовки контракта на разработку и поставку изделия поставщик должен представить заказчику следующие результаты АЛП:
  1. Показать, как и какие информационные технологии (ИТ) использованы при решении задач АЛП и как будет обеспечено совместное использование данных АЛП для ИЛП и других задач.
  2. Оценить характеристики "пригодности к поддержке", в том числе:
    • показать, как и какие ИТ будут применены в качестве одного из факторов, обеспечивающих заданный уровень "пригодности к поддержке";
    • оценить, как в проекте учтены ограничения на логистические ресурсы;
    • описать опыт применения ИТ в разработке и эксплуатации существующего изделия — прототипа;
    • показать, как и какие ИТ будут использованы в процессе проектирования для улучшения характеристик "обслуживаемости" изделия.
  3. Представить результаты оптимизации системы логистической поддержки.
  4. Оценить ресурсы, необходимые для логистической поддержки изделия.
На более поздних стадиях разработки (технический проект) и в процессе производства АЛП заключается в проектировании средств поддержки изделия, разработке перечня задач по обслуживанию и ремонту изделия и оценке ресурсов, необходимых для их выполнения. На этапе эксплуатации должен быть обеспечен сбор статистического материала для оценки результатов АЛП и для анализа новых проектов.
Вся информация, получаемая и используемая в процессе АЛП, должна храниться в специализированной базе данных АЛП. В БД АЛП фиксируется конкретная конфигурация изделия, требования и процедуры по обслуживанию. БД АЛП используется для разработки других элементов ИЛП, таких как электронная эксплуатационная документация, учебные материалы и т.д. На стадии эксплуатации в БД АЛП поддерживаются данные о фактической конфигурации изделия с учетом возможных изменений.
Информация о ходе эксплуатации и фактических характеристиках "пригодности к поддержке" должна передаваться проектанту, обеспечивая обратную связь и возможность дополнения и корректировки результатов первоначального анализа.
Поэтому БД АЛП физически должна состоять из двух частей: 1) непоставляемая часть, находящаяся в распоряжении подрядчика; 2) поставляемая часть, передаваемая заказчику. Поставляемая часть должна обеспечить функции обслуживания изделия заказчиком, в то время как непоставляемая часть должна обеспечивать функции логистической поддержки и сопровождения изделия подрядчиком. При поставке изделия подрядчик должен передать заказчику поставляемую часть БД АЛП, заполненную всей необходимой информацией о данном экземпляре изделия.


Системы технического обслуживания и ремонта
Планирование процессов технического обслуживания и ремонта (ТОиР) в системах интегрированной логистической поддержки предполагает:
  • разработку концепции ТОиР;
  • анализ и конкретизацию требований к изделию в части его обслуживания и ремонта;
  • разработку и оперативную корректировку плана ТОиР.
Концепция ТОиР предопределяет стратегию этих работ и их системную организацию.
Система ТОиР — совокупность взаимосвязанных технических средств, специальной технической документации и исполнителей, необходимых для поддержания и восстановления качества изделий, относящихся к компетенции этой системы.
Принято различать следующие виды ТО изделий:
  • ТО при использовании;
  • ТО при хранении;
  • ТО при перемещении;
  • ТО при ожидании использования по назначению.
Помимо перечисленных выше понятий, в стандарте DEF STAN 00-60 введено понятие уровня ТОиР, которое применительно к отечественным оборонным условиям может быть интерпретировано следующим образом:
  • нулевой уровень: ТОиР, выполняемые силами персонала, непосредственно эксплуатирующего изделие (экипажа);
  • первый уровень: ТОиР, выполняемые силами персонала подразделения (части), в составе которого эксплуатируется изделие (в армейских условиях — батальонные, полковые ремонтные службы);
  • второй уровень: ТОиР, выполняемые силами персонала соединения, в составе которого эксплуатируется изделие (корпусные, дивизионные, армейские ремонтные службы);
  • третий уровень: ТОиР, выполняемые силами персонала специализированных предприятий фронтового (окружного) подчинения;
  • четвертый уровень: ТОиР, выполняемые силами персонала предприятия-изготовителя.
Каждому уровню соответствует свой набор задач, требования к численности и квалификации обслуживающего и ремонтного персонала, к количеству и номенклатуре запасных частей и заменяемых агрегатов, к составу специального оборудования и т.д.
Конкретизация изложенных выше положений и представлений служит основой содержания концепции ТОиР, разрабатываемой, как правило, поставщиком изделия и согласуемой с его заказчиком.
Требования к изделию в отношении ТОиР определяются на основе данных АЛП , содержащихся в БД АЛП , и уточняются по результатам реальной эксплуатации в различных условиях.
На основе концепции и результатов анализа требований разрабатывают и реализуют следующие мероприятия:
  • создание единой системы управления ТОиР, предусматривающей методы и "механизмы" улучшения показателей надежности, безотказности, долговечности, ремонтопригодности, сохраняемости, что в итоге должно минимизировать эксплуатационные затраты;
  • организацию распределенной системы сбора и обработки службами заказчиков (эксплуатантов) статистической информации о значениях вышеуказанных показателей, а также данных о номенклатуре и количестве используемых запасных частей для изделия и его компонентов; эти данные извлекаются из специальных документов — формуляров изделия, его агрегатов и систем, в которых фиксируются результаты проведения операций ТОиР, факты замены компонентов, календарные сроки выполнения операций (начало, конец), сведения о работниках, выполнявших операцию и т.д.;
  • выполнение службами заказчиков и поставщика централизованного анализа накопленных эксплуатационных и логистических данных;
  • проведение согласованной динамической корректировки планов ТОиР;
  • подготовку и переподготовку персонала по обеспечению перечисленных выше мероприятий.
План ТОиР разрабатывается в нескольких альтернативных вариантах с учетом распределения работ по упомянутым выше уровням, назначения обслуживающего и ремонтного персонала, обладающего необходимой квалификацией, наличия необходимых запчастей и расходных материалов и т.д. Планируются календарные даты, трудоемкость работ и их стоимость. Заказчик выбирает наиболее подходящий ему вариант. При расчетах, связанных с планированием ТОиР, используются следующие основные показатели:
  • средняя продолжительность технического обслуживания (ремонта);
  • средняя трудоемкость технического обслуживания (ремонта);
  • средняя стоимость технического обслуживания (ремонта);
  • средняя суммарная продолжительность технических обслуживаний (ремонтов);
  • средняя суммарная трудоемкость технических обслуживаний (ремонтов);
  • средняя суммарная стоимость технических обслуживаний (ремонтов);
  • коэффициент готовности;
  • коэффициент технического использования.


Управление конфигурацией
Что в CALS-технологиях и системах PDM понимается под управлением конфигурацией изделия?
  1. Ремонтопригодность, понимаемая как легкость замены отказавших частей изделия;
  2. Сопровождение базы данных о свойствах изделия;
  3. Дисциплина внесения изменений в проект изделия, контроль версий проекта;
  4. Перестройка структуры изделия в процессе эксплуатации.
Ответ
  1. Неверно
  2. Ответ неконкретный
  3. Правильно (отмечено основное назначение управления конфигурацией)
  4. Неверно
При неверных ответах см. PDM.


Материально-техническое обеспечение
Системы материально-технического обеспечения (МТО) в составе систем интегрированной логистической поддержки предназначены для выполнения следующих процедур:
  • кодификация предметов материально-технического обеспечения (Codification);
  • определение параметров начального МТО (Initial Provisioning);
  • определение параметров текущего МТО (Provisioning);
  • планирование закупок (Procurement Planning);
  • управление поставками (Supply Management);
  • управление заказами (Order Administration);
  • управление счетами (Invoicing).
Кодификация предметов МТО представляет собой четко регламентированную стандартами процедуру присвоения этим предметам кодовых обозначений, однозначно понимаемых всеми причастными к соответствующим процессам службами поставщиков и потребителей. Характерной особенностью этих обозначений является их ориентированность на компьютерную обработку. Цель кодификации состоит в сокращении номенклатуры закупаемых изделий и комплектующих, исключении неоправданного дублирования и предоставлении необходимой информации потребителям и поставщикам.
Определение параметров начального МТО состоит в формировании перечня (набора) запасных частей и расходных материалов, необходимых для поддержки функционирования изделия в начальный период его эксплуатации, когда текущее МТО может по тем или иным причинам оказаться еще не налаженным. Состав этого набора как в отношении номенклатуры необходимых предметов, так и в отношении их количества, определяется расчетами, выполняемыми в процессе ЛА. В состав средств и предметов начального МТО, как правило, включают запасные части и материалы, необходимые для эксплуатации не только самого изделия, но и вспомогательного оборудования. В процессе организации начального МТО могут быть подготовлены контракты с фирмами — поставщиками соответствующей продукции. Обычно период действия начального МТО ограничивается сроком до двух лет.
Номенклатура и объемы поставок, т.е. параметры текущего МТО, также определяются расчетами, выполняемыми в процессе ЛА, и затем корректируются в зависимости от фактических условий эксплуатации изделия. При этом широко используются иллюстрированные каталоги деталей и элементов изделия, подготовка которых также происходит в процессе ЛА.
Планирование закупок (ПЗ), согласно упомянутым выше стандартам, представляет собой метод запроса и получения от промышленных предприятий сведений о ценах на предметы МТО, включая прайс-листы поставщиков. В соответствии со стандартами процедуры ПЗ охватывают два вида деловой практики:
  1. Процедуры направления запроса о ценах на конкретные предметы МТО от покупателя потенциальному поставщику и последующего ответа поставщика.
  2. Процедуры запроса покупателем актуального прайс-листа на некоторую номенклатуру предметов МТО и предоставления такого прайс-листа поставщиком в ответ на запрос покупателя.
Возможна также процедура предоставления этих данных покупателю по собственной инициативе поставщика. Стандарты жестко регламентируют форму и содержание запросов и ответов (сообщений) для обоих случаев, предусматривают формы и процедуры согласования цен и способы кодирования соответствующих разным ситуациям документов.
На основании результатов ПЗ определяется, у каких поставщиков будут приобретаться те или иные предметы МТО. Именно эти сведения и составляют содержание плана закупок. Эти данные используются на последующих стадиях ИЛП, т.е. при управлении заказами (заявками) и ведении счетов.
Управление поставками предусматривает выполнение таких процедур, как оценка уровня текущих запасов по всем предметам МТО, принятие своевременных решений о необходимости пополнения этих запасов, подготовку соответствующих заявок, контроль качества поступающих предметов МТО, организация их хранения и выдачи. На выполнение всех этих процедур существуют предусмотренные стандартами правила и инструкции, определяющие состав и последовательность необходимых действий, а также форму и содержание сопроводительных документов.
Управление заказами — термин, объединяющий все виды действий, осуществляемых с заказом (заявкой) от момента его выдачи заказчиком поставщику (с учетом возможных поправок/добавлений, запросов/справок о ходе выполнения и т.д.), вплоть до подтверждения доставки заказанных предметов МТО.
При выполнении этих действий между заказчиком и поставщиком осуществляется информационный обмен, в ходе которого используются следующие транзакции :
  1. Размещение заказа (Заказчик — Поставщик);
  2. Получение справок о размещенном заказе (Заказчик — Поставщик — Заказчик);
  3. Подтверждение приема заказа (Поставщик — Заказчик );
  4. Отказ от приема заказа (Поставщик — Заказчик);
  5. Извещение об изменении несущественных параметров заказа (Поставщик — Заказчик);
  6. Извещение о выполнении заказа (отгрузке) (Поставщик — Заказчик).
Формат и содержание транзакций регламентированы стандартами.
Управление счетами на оплату заказанных предметов снабжения — информационный обмен между поставщиком и заказчиком при передаче счетов и данных о счетах на оплату в электронном виде. При этом используются следующие транзакции:
  1. Отправка счета (Поставщик — Заказчик);
  2. Подтверждение приема счета к оплате (Заказчик — Поставщик);
  3. Отказ от оплаты счета (Заказчик — Поставщик);
  4. Отправка платежного требования (Поставщик — Заказчик);
  5. Прием платежного требования (Заказчик — Поставщик);
  6. Отказ от платежного требования (Заказчик — Поставщик);
  7. Запрос данных о состоянии платежа (Поставщик — Заказчик);
  8. Ответ на запрос о состоянии платежа (Заказчик — Поставщик);
  9. Извещение о состоянии платежа (Заказчик — Поставщик).
Формат и содержание транзакций регламентированы стандартами.


Интерактивные электронные технические руководства
Одним из важнейших компонентов ИЛП и CALS является обеспечение персонала эксплуатационной и ремонтной документацией, выполненной в электронном виде. Характерным свойством такой документации является ее интерактивность, т.е. возможность для обслуживающего и ремонтного персонала получать необходимые сведения о процессах и процедурах в форме прямого диалога с компьютером, Для реализации такой возможности, а также для презентаций проектов и для обучения персонала, занимающегося обслуживанием и эксплуатацией изделий, создаются технические руководства IETM — Interactive Electronic Technical Manual (или IETP — Interactive Electronic Technical Publication) и учебные пособия (ICW — Interactive Courseware). В них содержатся описания изделий, технологии эксплуатации, поясняются приемы обслуживания, методы диагностики и ремонта. В частности, в технических руководствах должны быть сведения о планировании регламентных работ, типовых отказах, способах обнаружения неисправностей и замены неисправных компонентов, испытательном оборудовании, способах заказа материалов и запасных частей и т.п.
Эксплуатационные документы должны создаваться в соответствии с концепциями, развиваемыми в CALS, обеспечивая повышенные удобства и эффективность освоения и эксплуатации сложной техники. Концепция создания и сопровождения электронной эксплуатационной документации получила название технологии IETM или ИЭТР (интерактивных электронных технических руководств).
В технологиях CALS к эксплуатационной документации IETM предъявляются повышенные требования. Это прежде всего представление документов в электронном виде, открытость пособий и руководств, т.е. их приспособленность к внесению изменений и конвертированию форматов, должная степень интерактивности и управления данными, адаптация учебного материала к конкретным запросам пользователей, малые затраты на создание документов для новых версий изделий.
Конкретизация задач ИЭТР представлена следующим списком:
  • обеспечение пользователя справочным материалом об устройстве и принципах работы изделия;
  • обучение пользователя правилам эксплуатации, обслуживания и ремонта изделия;
  • обеспечение пользователя справочными материалами, необходимыми для эксплуатации изделия, выполнения регламентных работ и ремонта изделия;
  • обеспечение пользователя информацией о технологии выполнения операций с изделием, потребности в необходимых инструментах и материалах, о количестве и квалификации персонала;
  • диагностика состояния оборудования и поиска неисправностей;
  • подготовка и реализация автоматизированного заказа материалов и запасных частей;
  • планирование и учет проведения регламентных работ;
  • обмен данными между потребителем и поставщиком.
Типичный состав ИЭТР :
  • описание устройства и функционирования изделия и его частей;
  • правила эксплуатации изделия, включая ограничения, подготовку, собственно использование;
  • диагностика оборудования и поиск неисправностей, ТОиР;
  • регламент технического обслуживания, планирование и учет регламентных работ;
  • Каталоги запасных частей, ведомости ЗИПа;
  • обмен информацией с заводом-поставщиком, автоматизированный заказ материалов и запасных частей;
  • Упаковка, транспортирование, консервация, хранение;
  • Утилизация.
Очевидна необходимость поддержки обмена данными между заказчиком и поставщиком.
Для создания и применения ИЭТР используются специализированные программные продукты, примером которых может служить комплекс Technical Guide Builder (TGB), разработанный НИЦ CALS-технологий "Прикладная логистика".
ИЭТР включает в себя базу данных (БД) и электронную систему отображения (ЭСО).
Задачи ИЭТР решаются благодаря специфическим формам и методам организации БД и способам доступа к ней. По существу ИЭТР является своеобразной базой знаний об изделии и в этом качестве представляет собой интеллектуальное средство поддержки эксплуатации изделия на постпроизводственных стадиях жизненного цикла изделия. База данных ИЭТР имеет структуру, позволяющую пользователю быстро получить доступ к нужной информации. Она может содержать текстовую и графическую информацию, а также данные в мультимедийной форме (аудио- и видеоданные).
ЭСО предназначена для визуализации данных и обеспечения интерактивного взаимодействия с пользователем. Способ взаимодействия с пользователем и техника представления информации унифицированы для всех ИЭТР.
В технологиях ИЭТР используется ряд стандартов. Кроме стандарта ISO 8879 (SGML), здесь находят применение стандарт ISO 10744 (HyTime — Hypermedia / Time-based Document Structuring Language), спецификации MIL-87268...87270 и др. Так, документ MIL-M-87268 (Interactive Electronic Technical Manual Content) определяет общие требования к содержанию, стилю, формату и средствам диалогового общения пользователя с интерактивными электронными техническими руководствами. В спецификации MIL-D-87269 содержатся требования к базам данных для интерактивных электронных технических руководств и справочников, описаны методы представления структуры и состава промышленного изделия и его компонент на языке SGML, даны шаблоны документов на составные части технической документации, перечислены типовые элементы документов. Подробно описана схема внутреннего построения баз данных на основе конструкций и элементов языка SGML. В авиационной промышленности для создания ИЭТР руководствуются спецификацией AECMA S1000D.
В России интерактивные электронные технические руководства выполняются в соответствии с нормативно-техническими документами, принятыми Госстандартом в 2001 г. и определяющими общие требования к логической структуре, содержанию, стилю и оформлению иерархически структурированных ИЭТР:
  • Р 50.1.029—2001. Информационные технологии поддержки жизненного цикла продукции. Интерактивные электронные технические руководства. Общие требования к содержанию, стилю и оформлению. Рекомендации по стандартизации. Госстандарт России. Москва, 2001г.
  • Р50.1.030-2001. Информационные технологии поддержки жизненного цикла продукции. Интерактивные электронные технические руководства. Требования к логической структуре базы данных. Рекомендации по стандартизации. Госстандарт России. Москва, 2001г.
Согласно этим документам ИЭТР представляет собой структурированный программно-аппаратный комплекс, содержащий взаимосвязанные технические данные, требующиеся при эксплуатации, обслуживании и ремонте изделия. ИЭТР предоставляет в интерактивном режиме справочную и описательную информацию об эксплуатационных и ремонтных процедурах, относящихся к конкретному изделию, непосредственно во время проведения этих процедур.
В ИЭТР используют классификацию документов. По одной из существующих систем классификации выделяют следующие классы ИЭТР:
  • Класс 1 — Бумажно-ориентированные электронные документы. Отсканированные страницы бумажных руководств. Электронный документ — копия бумажного руководства. Преимущества: большие объемы бумажной документации заменяет компактный электронный носитель. Недостатки: не добавляет никаких новых функций по сравнению с бумажными руководствами.
  • Класс 2 — Неструктурированные документы. Текстовые электронные документы. Преимущества: возможность использования аудио- и видеофрагментов, графических изображений и возможность осуществлять поиск по тексту документа. Недостатки: ограниченные возможности обработки информации.
  • Класс 3 — Структурированные документы. Начиная с класса 3, руководства представляют собой документы, имеющие три компонента: структура, оформление и содержание. Кроме того, начиная с класса 3, ИЭТР имеют стандартизированный интерфейс пользователя. Преимущества: существует возможность стандартизировать структуру, оформление и пользовательский интерфейс руководств (например, в соответствии с отраслевыми стандартами на эксплуатационную документацию), стандартизированный интерфейс пользователя позволяет облегчить работу с ИЭТР. Недостатки: при создании руководств к сложным промышленным изделиям появляются проблемы управления большим объемом информации.
  • Класс 4 — Интерактивные базы данных. Преимущества: можно создавать технические руководства большого объема. Недостатки: отсутствие системы диагностики изделия.
  • Класс 5 — Интегрированные базы данных. Дают возможность прямого взаимодействия с электронными модулями диагностики изделий, что существенно облегчает обслуживание и ремонт изделия. Преимущества: возможность проведения диагностики изделия. Недостатки: очень высокая стоимость создания. Вариант использования конкретного класса ИЭТР, в общем случае, зависит от сложности изделия, от финансовых и технических возможностей пользователя.


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


Express и Express-G (пример 3)
Создайте модель на языках Express-G и Express для ситуации:
Фрагмент (fragment) 2D-изображения представлен окружностью (circle) или отрезком кривой (curve), кроме того, свойством фрагмента является цвет (colour). Окружность характеризуется радиусом (rad), отрезок кривой - тремя точками (P).
Ответ

Рис. 1.

SCHEMA DIAG1;
  TYPE form = SELECT
    (cicle,
     curve);
  END_TYPE;
  TYPE colour = ENUMERATION OF
    (RED,
     BLUE,
     WHITE);
  END_TYPE;
  ENTITY cicle;
      rad : REAL;
  END_ENTITY;
  ENTITY curve;
      P : ARRAY [1:3] OF point;
  END_ENTITY;
  ENTITY point;
      X : ARRAY [1:2] OF REAL;
  END_ENTITY;
  ENTITY fragment;
      figure : form;
      image  : colour;
  END_ENTITY;
END_SCHEMA;


Управление качеством
Система управления качеством на промышленных предприятиях основана на CALS-технологиях, стандартах ISO 9000 и TQM Total Quality Management).
В наиболее общем виде управление качеством сводится к выполнению ряда процедур, представленных на рис. 1.
Рис. 1. Процедуры управления качеством
Федеральный институт качества США сформулировал семь рабочих принципов, которые в совокупности дают определение TQM. Это:
- Демонстрация поддержки и персонального руководства мероприятиями по оптимизации процессов со стороны руководителей организации;
- Стратегическое планирование кратко— и долгосрочных направлений деятельности организации и объединение усилий по борьбе за качество со стратегическим планированием;
- Обеспечение концентрации каждого работника на потребностях и ожиданиях клиентов;
- Разработка четко определенных мер по фиксированию изменений и улучшений и обнаружению возможностей усовершенствования;
- Выделение адекватных ресурсов на обучение и стимулированию работников к повышению качества процессов;
- Наделение работников полномочиями для принятия решений и поощрение командной работы;
- Разработка систем, обеспечивающих осуществление контроля качества с самого начала и на протяжении всех операций.


Express и Express-G (пример 4)
Создайте модель на языках Express-G и Express для ситуации:
Сущность Локальная вычислительная сеть (LAN) имеет атрибуты Метод доступа (access), Число узлов (numb_nodes) и наследует параметр Топология (topology) от сущности Структура (structure) и параметр rang от сущности Управление (control).
Ответ
Рис. 1.
SCHEMA DIAG2;

  TYPE line = ENUMERATION OF
    (BUS,
     STAR,
     RING);
  END_TYPE;

  TYPE conf = ENUMERATION OF
    (ONE_RANG,
     CLIENT_SERVER);
  END_TYPE;

  ENTITY structure;
      topology : line;
  END_ENTITY;

  ENTITY control;
      rang : conf;
  END_ENTITY;

  ENTITY LAN
    SUBTYPE OF(structure, control);
      numb_nodes : INTEGER;
      access     : STRING;
  END_ENTITY;

END_SCHEMA;


Стандарты управления качеством промышленной продукции
Управление качеством включает следующие виды деятельности:
  • сбор и анализ информации о производственных процессах и от потребителей продукции;
  • выработка и корректировка целей и принятие решение, направленных на реализацию целей;
  • распределение и перераспределение ресурсов.
Международные стандарты серии ISO 9000 разработаны для управления качеством продукции, их дополняют стандарты серии ISO 14000, отражающие экологические требования к производству и промышленной продукции. Хотя эти стандарты непосредственно не связаны со стандартами STEP, их цели — совершенствование промышленного производства, повышение его эффективности — совпадают.
Очевидно, что управление качеством тесно связано с его контролем. Контроль качества традиционно основан на измерении показателей качества продукции на специальных технологических операциях контроля и выбраковкой негодных изделий. Однако есть и другой подход к управлению качеством, основанный на контроле качественных показателей не самих изделий, а проектных процедур и технологических процессов, используемых при создании этих изделий. Такой подход более эффективен. Он требует меньше затрат, поскольку позволяет обойтись без 100% контроля продукции и, благодаря предупреждению появления брака, снижает производственные издержки. Именно этот подход положен в основу стандартов Международной организации стандартизации ISO 9000, принятых ISO в 1987 г. и проходящих корректировку приблизительно каждые пять лет.
Таким образом, методической основой для управления качеством являются международные стандарты серии ISO 9000. Они определяют и регламентируют инвариантные вопросы создания, развития, применения и сертификации систем качества в промышленности. В них устанавливается форма требований к системе качества в целях демонстрации поставщиком своих возможностей и оценки этих возможностей внешними сторонами.
Основными причинами появления стандартов ISO 9000 были потребности в общем для всех участников международного рынка базисе для контроля и управления качеством товаров. Американское общество контроля качества (ASQC) определило цели ISO 9000 как помощь в развитии международного обмена товарами и услугами и в кооперации в сфере интеллектуальной, научной, технологической и деловой активности.
В стандартах ISO 9000 используется определение качества продукции из стандарта ISO 8402, в котором под качеством продукции подразумевается своевременное удовлетворение требований заказчика при приемлемой цене. Вводится понятие системы качества (QS — Quality System), как документальной системы с руководствами и описаниями процедур достижения качества. Другими словами, система качества есть совокупность организационной структуры, ответственности, процедур, процессов и ресурсов, обеспечивающая осуществление общего руководства качеством.
Система качества обычно представляет собой совокупность трех слоев документов. Слои содержат:
  1. описание политики управления для каждого системного элемента (организация, ответственные, контроль);
  2. описание процедур управления качеством (что, где, кем и когда должно быть сделано);
  3. тесты, планы, инструкции и т.п.
Сертификация предприятий по стандартам ISO 9001-9003 выполняется некоторой уполномоченной внешней организацией. Наличие сертификата качества — одно из важных условий для успеха коммерческой деятельности предприятий.
Стандарты серии ISO 9000 управления качеством промышленной продукции делятся на первичные, вторичные и поддерживающие.
В свою очередь, первичные стандарты делятся на внешние и внутренние. Внешние стандарты инвариантны к приложениям, они описывают требования, соблюдение которых гарантирует качество при выполнении контрактов с внешними заказчиками. Внутренние стандарты предназначены для внутреннего использования, они описывают мероприятия по управлению качеством внутри компании.
ISO предлагает следующие внешние стандарты:
  • ISO 9001 — модель качества, достигаемого при проектировании, производстве, обслуживании;
  • ISO 9002 — сокращенная по сравнению с ISO 9001 модель (без процессов проектирования);
  • ISO 9003 — модель качества при финальном тестировании продукции.
Вторичные стандарты включают в себя:
  • ISO 9000 — основные понятия, руководство по применению ISO 9001;
  • ISO 9004 — элементы систем управления качеством.
В стандарте ISO 9004 содержатся 20 основных требований к качеству, называемых системными элементами. Системные элементы разделены на группы, относящиеся к производству, транспортировке и постпроизводственным операциям, документации продукции, маркетингу. Например, при производстве контролируются планирование, процедуры, программы и инструкции для управления и улучшения производственных процессов. При маркетинге контролируются такие системные элементы, как функциональное описание продукции, организация обратной связи с заказчиками (отслеживание и анализ рекламаций).
Поддерживающие стандарты предназначены для развития и установки систем качества:
  • ISO 10011 — аудит, критерии для аудита систем качества;
  • ISO 10012 — метрологическое подтверждение качества;
  • ISO 10013 — пособие для развития руководств по управлению качеством.
Часть этих стандартов утверждена в качестве государственных стандартов РФ. В частности, это:
  • ГОСТ Р ИСО 9001-96 "Системы качества. Модель обеспечения качества при проектировании, разработке, производстве, монтаже и обслуживании";
  • ГОСТ Р ИСО 9002-96 "Системы качества. Модель обеспечения качества при производстве, монтаже и обслуживании";
  • ГОСТ Р ИСО 9003-96 "Системы качества. Модель обеспечения качества при окончательном контроле и испытаниях".
В настоящее время разработана новая версия стандартов серии ISO 9000 под названием ISO 9000:2000 Quality management systems (Системы управления качеством), в которую включены документы:
  • ISO 9000:2000 Fundamentals and vocabulary (Основы и терминология);
  • ISO 9001:2000 Requirements (Требования к системам качества);
  • ISO 9004:2000 Guidelines for performance improvement (Руководство по развитию).
Главные отличия новой версии от предыдущей обусловлены стремлением упростить практическое использование стандартов, направлены на их лучшую гармонизацию и заключаются в следующем.
В стандарте ISO 9001 минимизируется объем требований к системе качества. Стандарты ISO 9002-9003 из новой версии исключаются. Расширяется круг контролируемых ресурсов, в их число включены такие элементы, как информация, коммуникации, инфраструктура. 20 элементов качества из стандарта ISO 9004 сворачиваются в 4 группы: распределение ответственности (management responsibility); управление ресурсами (resource management); реализация продукции и услуг (product and/or service realization); измерения и анализ (measurement, analysis, and improvement).


Express и Express-G (пример 5)
Создайте модель на языках Express-G и Express для ситуации:
Проект (project) состоит из пояснительной записки (text) и графического материала (graphics), атрибуты проекта - автор (author), название (titul), атрибуты записки - число страниц (pages) и аннотация (annot), атрибуты графики - число листов (numb) и форма представления (present). Число листов должно быть больше 9.
Ответ
Рис. 1.
SCHEMA DIAG4;

  ENTITY project;
      author : STRING;
      titul  : STRING;
  END_ENTITY;

  ENTITY text
    SUBTYPE OF(project);
      pages : INTEGER;
      annot : STRING;
  END_ENTITY;

  ENTITY graphics
    SUBTYPE OF(project);
      numb    : INTEGER;
      present : STRING;
    WHERE
      restr : numb>9;
  END_ENTITY;

END_SCHEMA;


Программное обеспечение CALS-технологий
Программное обеспечение CALS-технологий должно выполнять те функции, которые обеспечивают создание и поддержку интегрирующей информационной среды для промышленных автоматизированных систем.
Во-первых, это функции управления данными, разделяемыми разными автоматизированными системами и подсистемами на этапах жизненного цикла изделий. Эти функции в настоящее время выполняют системы управления жизненным циклом PLM или на этапе проектирования — системы управления проектными данными PDM.
Во-вторых, это функции управления данными и программами в распределенной сетевой среде, включая функции защиты информации. Эти функции реализуются в технологиях распределенных вычислений таких, как удаленный вызов процедур RPC, архитектура на основе посредников объектных запросов CORBA, объектная модель COM/DCOM, технология SOAP и др. На базе COM/DCOM фирма Microsoft развивает совокупность средств под названием DNA-архитектура (Distributed interNet Application). Эти средства включают целую гамму инструментов, таких как ActiveX, HTML, SQL Server, OLE и др Применительно к промышленным приложениям эта архитектура получила название DNA for Manufacturing (DNA-M). Использование DNA-M позволяет разработчикам CALS-средств сконцентрировать усилия на решении специфичных задач и не тратить время на реализацию взаимодействия в сетевой среде. Особенно важную роль DNA-M сыграет в интеграции нижних уровней управления производством с системами ERP.
В-третьих, это программные средства логистической поддержки изделий, обслуживания сложной техники и обучения обслуживающего персонала правилам эксплуатации и ремонта изделий, представленные, в частности, интерактивными электронными техническими руководствами (ИЭТР), создаваемыми в CALS-системах с помощью специальных инструментальных средств. Развитые ИЭТР служат не только целям обучения пользователей, но выполняют также функции автоматизированного заказа материалов и запасных частей, планирования и учета проведения регламентных работ, обмена данными между потребителем и поставщиком, диагностики оборудования и поиска неисправностей. Примерами инструментальных систем создания ИЭТР могут служить TG Builder (компания "Прикладная логистика") или Adobe frameMaker+SGML (Adobe).
В-четвертых, к программному обеспечению CALS-технологий следует отнести многочисленные средства поддержки моделирования и обмена данными с использованием языка Express, которые можно объединить под названием STEP-средств (STEP Tools). К STEP-средствам относятся редакторы, компиляторы, визуализаторы, анализаторы, конверторы и т.п., связанные с языком Express. Редакторы помогают синтезировать и корректировать Express-модели. Анализаторы служат для синтаксического анализа и выявления ошибок, допущенных при написании модели. Анализатор входит в состав компилятора, который после анализа осуществляет трансляцию Express-моделей в ту или иную требуемую языковую форму. Визуализаторы генерируют графические представления моделей на языке Express-G. Конверторы используются для преобразования Express-моделей на основе языка Express-X.
В-пятых, программному обеспечению CALS-технологий можно отнести средства поддержки языков SGML, XML, EDIFACT.
Примерами STEP-средств могут служить продукты компаний STEP Tools, EPM Technology AS, TNO и др.
Например с помощью программ ST-Developer компании STEP Tools реализуют SDAI-интерфейс на языках C, C++, Java, IDL/Corba, интерфейс Express-моделей к SQL базам данных и графическому ядру ACIS машиностроительных CAD-систем, осуществляют тестирование Express-моделей, генерируют модели на языке Express-G.
Ряд STEP-средств предлагает Национальный институт стандартов и технологий США (NIST). Это средства оперирования обменными файлами и Express-моделями, трансляции моделей в C++ и IDL представления.
Компания Rational Rose предлагает транслятор Express-моделей в UML-представление.
Программные средства компании EPM Technology AS, составляющие систему EDM (Express Data Manager), характеризуются разнообразием выполняемых функций. Так, программа EDMdeveloperSeat поддерживает базу данных с Express-моделями, EDMvisualExpress осуществялет визуализацию моделей с помощью расширения языка Express-G, EDMmodelChecker служит для диагностики допущенных нарушений правил языка Express.
Технологии распределенных вычислений и их программное обеспечение используются, но не являются специфичными в CALS-приложениях. Поэтому основными компонентами ПО CALS являются системы PDM (или их развитие в виде систем CPC и PLM) и интерактивные электронные технические руководства (IETM).
Системы PDM предназначены преимущественно для информационного обеспечения проектирования — упорядочения информации о проекте, управления соответствующими документами, включая спецификации и другие виды представления данных, обеспечения доступа к данным по различным атрибутам, навигации по иерархической структуре проекта. В ряде систем PDM поддерживаются информационные связи не только внутри САПР, но также с производственной и маркетинговой документацией. Аналогичные системы, в большей мере ориентированные на управление информацией в системах типа ERP, SCM, CRM и т.п., часто называют системами EDM (Enterprise Data Management).
В последнее время усилия многих компаний, производящих программно-аппаратные средства автоматизированных систем, направлены на создание систем электронного бизнеса (E-commerce). В основе развитых систем E-commerce лежит управление данными на протяжении всего жизненного цикла изделий, т.е. CALS-технологии, средства PDM и CPC.
Среди систем E-commepce различают системы B2C и B2B.
Система B2C (Business-to-Customer) предназначена для автоматизации процедур взаимоотношений предприятия с конечными потребителями его продукции, чаще всего это взаимоотношения юридического лица с физическими лицами (покупателями товаров).
Но значимость систем E-commerce отнюдь не определяется организацией электронной торговли путем размещения на сайтах Internet витрин товаров и услуг. Цель электронного бизнеса заключается в объединении в едином информационном пространстве информации, во-первых, о возможностях множества организаций, специализирующихся на предоставлении различных услуг и на выполнении тех или иных процедур и операций по проектированию и изготовлению заказанных изделий, во-вторых, о запросах на использование этих услуг и заказах на поставки изделий и полуфабрикатов. В отличие от B2C такие E-commerce системы называют системами B2B (Business-to-Business). Эти системы автоматизируют процедуры взаимодействия юридических лиц друг с другом, более конкретно, системы B2B автоматизируют процессы обмена информацией между компаниями-партнерами.
Возникает задача создания единого информационного пространства, в котором функционируют автоматизированные системы управления взаимодействующих предприятий. Системы управления данными в интегрированном информационном пространстве называют системами CPC.
Технология интегрированного информационного пространства и управления данными CPC — технология взаимодействия производителей, поставщиков и покупателей на различных этапах жизненного цикла изделий, направленная на оптимальное удовлетворение потребностей заказчиков в продукции и услугах. Благодаря более высокой степени специализации предприятий, проектированию под заказ, комплексному учету затрат на проектирование, изготовление, доставку продуктов можно минимизировать временные и финансовые затраты при высоком качестве изделий. Чтобы использовать эти возможности, требуются специальные системы CPC, главное назначение которых — обеспечивать информационную согласованность действий всех участников процесса создания продукции. В CPC учитывается, что число участников в цепи поставок может быть весьма значительным, причем состав участников непостоянен, а определяется исходя из конкретных задач и условий. Для эффективного управления процессами на протяжении всего жизненного цикла продукции все участники должны пользоваться доступными для правильного восприятия, интерпретации и исчерпывающе полными данными.
Системы CPC интегрируют функции таких систем, как SCM, CRM, а также часть функций систем PDM, CAD/CAM и ERP.
В большинстве автоматизированных систем для обменов данными внутри системы используют те или иные форматы, или не являющиеся унифицированными, или признанные в ряде систем лишь как стандарты де-факто. Языки типа Express используют для межсистемных обменов и представления многократно используемых данных в общих базах данных, для выполнения роли внутренних форматов они неудобны. Поэтому в прикладные автоматизированные системы для связей с общей информационной CALS-средой должны быть включены конверторы для взаимных преобразований внутренних форматов данных в STEP-форматы. Такие конверторы также относят к программному обеспечению CALS-технологий.
В PDM разнообразие типов проектных данных поддерживается их классификацией и соответствующим выделением групп с характерными множествами атрибутов. Такими группами данных являются аспекты описания, т.е. описания изделий с различных точек зрения. Для большинства САПР машиностроения характерными аспектами являются свойства компонентов и сборок (эти сведения называют Bill of materials — BOM), модели и их документальное выражение (основными примерами могут служить чертежи, 3D модели визуализации, сеточные представления для конечно-элементого анализа, текстовые описания), структура изделий, отражающая взаимосвязи между компонентами и сборками и их описаниями в разных группах.
Вследствие большого объема проектных данных и наличия ряда версий проектов PDM должна обладать развитой системой поиска нужных данных по различным критериям.
Примеры PDM
В настоящее время (2006 г.) наиболее известными PDM-системами являются ENOVIA и SmarTeam (Dessault Systemes), Teamcenter (Unigraphics Solutions), Windchill (PTC), mySAP PLM (SAP), BaanPDM (BAAN) и российские системы Лоцман:PLM (Аскон), PDM StepSuite (НПО "Прикладная логистика"), Party Plus (Лоция Софт).
Основные разработчики САПР в машиностроении считают целесообразным предлагать комплексные системы PLM, в состав которых входят как модули CAD/CAM/CAE, так и PDM.
Так, компания Dessault Systemes создает систему ENOVIA на базе приобретенной PDM ProductManager. ENOVIA предназначена для моделирования и управления данными об изделиях, процессах и ресурсах на различных этапах жизненного цикла промышленной продукции от концептуального проектирования до эксплуатационного обслуживания. Это распределенная на базе Web-технологий система управления данными, способствующая интеграции систем проектирования, производства и управления внутри предприятия и позволяющая отдельным фирмам объединяться в виртуальные предприятия. Управление проектами и изменениями данных, их распределение, интерфейс с системами ERP — далеко не полный перечень функций этой системы.
Кроме ENOVIA, Dessault Systemes развивают систему SmartTeam. В базовый комплект системы SmarTeam входят модуль создания и редактирования моделей, СУБД (Interbase или Oracle), визуализатор, модуль сопряжения с различными САПР (в список входят SolidWorks, MDT, Inventor, Microstation, Solid Edge, AutoCAD 14). Базовый комплект может расширяться путем добавления модулей документооборота, интеграции с ERP, SCM и CRM-системами, взаимодействия с партнерами через Internet и др. Состав системы SmarTeam и ее связи с CAD и ERP-системами иллюстрирует рис. 1.
Создаваемая в среде SmarTeam информационная модель объекта состоит из двух частей. Одна часть служит для описания состава изделия (в виде дерева), его структуры (в виде файлов с данными о сборках), геометрии и материала деталей. Другая часть содержит данные о технологических процессах изготовления объекта в виде дерева операций и переходов и автоматически формируемой технологической документации.
Рис. 1. Состав системы SmarTeam
Unigraphics Solutions осуществила преобразование систем iMAN и Metaphase в новую PDM Teamcenter. В этой PDM имеются подсистемы управления данными на стадиях проектирования и производства.
Компания PTC располагает двумя системами PDM — это Pro/Intralink и более современная Windchill. Система Windchill основана на использовании Internet и Web-технологий для информационного взаимодействия многих предприятий и потому может позиционироваться как система CPC. Windchill охватывает все этапы проектирования, выполняет функции, которые присущи системам документооборота, управления проектами, конфигурацией и изменениями проектных данных. Системы CPC функционируют в гетерогенной среде, охватывающей пространство, не ограниченное рамками отдельных предприятий и корпораций. Система CPC, отвечая на запросы пользователей, может собирать необходимые данные из web-сайтов, баз данных ERP или PDM систем и, преобразуя в единый формат, предоставляет их пользователю. Имеются возможности планирования и моделирования производственных и логистических процессов.
В SolidWorks используется PDM/Works, в SolidEdge — заимствованная система управления документами SharePoint Portal Server.
Компания Consistent Software разрабатывает оригинальную PDM-систему OutdoCS PDM и предлагает комплексную систему PartY Plus, разработанную фирмой Лоция Софт. Система PartY Plus предназначена для управления информацией об изделиях, проектах, сооружениях на протяжении всех этапов их жизненного цикла. PartY Plus включает в себя три основных продукта, которые могут использоваться как автономно, так и совместно — это PDM PartY, система управления документами DOCS Open, управления документооборотом и бизнес-процессами LS Flow. В качестве СУБД нужно использовать одну из систем Sybase Adaptive Server, MS SQL Server или Oracle.
На роль PDM претендует система ведения архива технической документации и управления проектными данными Search белорусской фирмы Интермех. Search выполняет функции: хранение документов (чертежи, спецификации, руководства и др.), поиск и доступ к ним, управление версиями документов и изменениями в них, визуализация структуры изделий в виде дерева связей, поддержка групповой работы над проектом (редактирование, маршрутизация документов), формирования различного рода справок и отчетов, регулирование прав доступа к архиву, импорта данных из внешних баз. Архив создается на базе СУБД Oracle или InterBASE (компания Borland). Обеспечивается удаленный доступ к архиву с помощью Web-браузеров. В системе имеются редактор спецификаций, редактор извещений об изменениях в проекте, модуль доступа к документам, расположенным на других узлах сети, база данных (электронный архив), текстовый редактор, объединенные с чертежной системой. Search "понимает" внутренний язык AutoCAD. Для ее использования необходима СУБД Interbase (компания Borlabd).
Белорусская компания Омегасофтвер разработала систему Omega Production, в которой предусмотрены структурирование данных об изделиях, технологических процессах, оснастке и оборудовании, управление документами и документооборотом, управление конфигурацией изделий, контроль изменений, вносимых в проект, интерфейс с другими САПР. Кроме того, в Omega Production имеются модули оперативного управления производством, контроля качества продукции, управления запасами и поставками материалов и комплектующих, что характерно для логистических систем. Следовательно, Omega Production может служить основой для интеграции систем проектирования и управления предприятием.


Express и Express-G (пример 6)
Создайте модель на языках Express-G и Express в виде двух схем для ситуации:
Первая схема - сущность person с атрибутами first_name, family типа string; атрибутами age, tabl типа integer; атрибутом sex типа enumeration со значениями man и woman;
Вторая схема - сущность specialist с атрибутом position типа subdivision (в свою очередь, имеющего атрибут ind типа string) и атрибутом name_sp типа employee со ссылкой на сущность person из первой схемы.
Ответ
Рис. 1. Схемы на языке Express-G, полученные с помощью системы EDMvisualExpress
Рис. 2. Модель на языке Express, полученная с помощью системы EDMSupervisor


Автоматизированные системы делопроизводства
Информационные технологии и АСУ документами и документооборотом пользуются все возрастающим вниманием среди предприятий и фирм различного профиля, поскольку организация работы с документами существенно влияет на эффективность производственных и бизнес-процессов. Такие системы имеют как самостоятельное значение, так и играют важную роль в интегрированных АС управления и проектирования.
Автоматизированные системы делопроизводства (АСД) по своему назначению подразделяют на системы управления документами (СУД), управления документооборотом (СДО), управления знаниями (в сфере делопроизводства) и инструментальные среды делопроизводства. В соответствии с другими критериями классификации системы делопроизводства подразделяют на специализированные и комплексные, локальные и распределенные, фактографические и документографические (полнотекстовые), заказные и тиражируемые.
Системы управления техническими документами и документооборотом, относящиеся к сфере проектирования и производства в промышленности, называют системами управления техническими данными или системами TDM (Technical Data Management). Специфические отличия систем TDM от офисных АСД заключаются в большом числе чертежной документации и в тесной взаимосвязи с САПР.
Системы управления документами предназначены для обеспечения санкционированного доступа к документам. Характерные функции СУД:
  • ввод документов, в частности, с помощью средств их автоматического распознавания;
  • индексирование документов, например, оформление регистрационных карточек с полями для атрибутов; возможно атрибутивное индексирование — к атрибутам относятся автор документа, дата создания и ключевые слова или полнотекстовое индексирование — в индекс заносят весь текст, но без предлогов и окончаний некоторых слов;
  • хранение документов;
  • поиск нужных данных, который может быть атрибутивным в фактографических БД или полнотекстовым в случае слабоструктурированных документов;
  • поддержка групповой работы над документами;
  • разграничение прав доступа к документам;
  • контроль и управление версиями документов, регламентирующие внесение в них изменений;
  • сбор и анализ статистических данных по параметрам документов и функционированию системы;
  • подготовка отчетов.
Системы управления документооборотом (называемые также Workflow) служат для управления деловыми процессами прохождения и обработки документов в соответствующих подразделениях и службах организации. Характерные функции СДО:
  • регистрация документов при их вхождении в систему;
  • маршрутизация документов, учет их движения (маршрутизация может быть жесткой при фиксированных маршрутах или свободной); управление потоками документов обеспечивает прохождение документов по заданному маршруту с контролем внесения в них резолюций, управление внесением изменений включает систему приоритетов, средства протоколирования изменений;
  • контроль исполнения предписываемых документами действий;
  • защита информации при ее передаче между пунктами распределенной системы;
  • автоматическое уведомление соответствующих лиц о состоянии документов и содержащихся в них директив и рекомендаций;
  • планирование работ, связанных с прохождением документов.
К системам управления знаниями в области делопроизводства относят системы, выполняющие функции, характерные для интеллектуальных систем. Примеры таких функций:
  • классификация документов по тем или иным признакам;
  • взаимное связывание документов, например, с помощью гипертекста;
  • тематический отбор документов;
  • интеграция данных, поступающих из различных источников;
  • аналитическая обработка данных;
  • моделирование деловых процессов.
Инструментальные среды в системах делопроизводства служат для формирования АСД, адаптированных к условиям конкретных предприятий и фирм. Часто такое формирование проводится путем дополнения некоторого базового компонента, в состав системы входит соответствующий язык расширения.
Кроме перечня решаемых задач, выделяют следующие свойства и характеристики АСД:
  • открытость, программные интерфейсы и форматы данных для обмена с другими информационными системами;
  • мобильность для инсталляции на ведущих платформах;
  • модульное построение, что обеспечивает масштабируемость — возможность эволюционного развития, адаптируемость, возможность внедрения на предприятиях по частям;
  • пользовательский интерфейс;
  • быстродействие, временные затраты на выполнение задач;
  • уровень защиты информации;
  • соответствие стандартам информационных технологий;
  • операционные среды и используемые СУБД, требования к аппаратным ресурсам;
  • перенос документов по мере их устаревания на более дешевые носители.
Основными компонентами систем управления документами и документооборотом являются электронный архив, система маршрутизации документов и контроля исполнения, модули сопряжения с прикладными программами, средства ввода информации с бумажных носителей.
В крупных АСД предусматривается распределенное хранение с доступом к документам в режимах как off-line, так и on-line. В первом случае пользователь формирует запрос в виде совокупности ключевых слов и направляет его средствами электронной почты (E-mail), СДО выдает список релевантных документов, пользователь выбирает из списка нужные документы и посылает вторичный более конкретный запрос, получая по E-mail запрошенные документы. Во втором случае используется связь в реальном времени, документ вызывается на экран компьютера и пользователь может непосредственно его просматривать и редактировать.
Современные корпоративные системы делопроизводства являются распределенными, имеющими архитектуру клиент-сервер. На серверной стороне находят применение серверы баз данных, полнотекстовых документов, электронной почты, приложений, SQL- и Web-серверы. На клиентской стороне могут выделяться рабочие места пользователей, администратора и разработчиков баз данных, информационно-поисковых систем, форм документов и т.п. В частности, применяются трехзвенные распределенные системы.
К широко известным СДО и АСД относятся Lotus Notes, Docs Open, ДЕЛО-96 и др. Примерами систем TDM на 20...30 одновременно работающих пользователей могут служить Search или T-Flex DOCs и на большее число пользователей — системы документооборота, используемые в PDM Optegra или iMAN.


Express и Express-G (пример 7)
Дана модель в виде схемы рис. 1 на языке Express-G. Требуется записать модель на языке Express и создать обменный файл.
Рис. 1.
Ответ
Express- схема:
SCHEMA OFF;
  ENTITY docum;
      time : date;
  END_ENTITY;
  ENTITY letter
    SUBTYPE OF(docum);
      text   : STRING;
      s_from : source;
  END_ENTITY;
  ENTITY order
    SUBTYPE OF(docum);
      numb : INTEGER;
  END_ENTITY;
  ENTITY source;
  END_ENTITY;
  ENTITY company
    SUBTYPE OF(source);
      address : STRING;
      org     : STRING;
  END_ENTITY;
  ENTITY person
    SUBTYPE OF(source);
      family     : STRING;
      first_name : STRING;
  END_ENTITY;
  ENTITY date;
      month : STRING;
      day   : INTEGER;
      year  : INTEGER;
  END_ENTITY;
END_SCHEMA;
Обменный файл:
ISO-10303-21;
HEADER;
FILE_DESCRIPTION((),'2;1');
FILE_NAME('m2','2006-03-10T07:44:25',('ANONYMOUS USER'),('ANONYMOUS ORGANISATION'),'EXPRESS Data Manager version 20050406',$,$);
FILE_SCHEMA(('OFF'));
ENDSEC;

DATA;
#1= LETTER(#2,'This is...',#3);
#2= DATE('mart',4,2006);
#3= COMPANY('Moscow, 2d Baumanskaya str., 5','BMSTU');
#4= LETTER(#2,'Dear...',#5);
#5= PERSON('Petrov','Ivan');
#6= ORDER(#7,24);
#7= DATE('April',2,2005);
ENDSEC;

END-ISO-10303-21;


Стандарт DEF STAN 00-60
Стандарт DEF STAN 00-60 посвящен интегрированной логистической поддержке, разработан в Великобритании и де-факто стал международным стандартом.
Состоит из 12 частей, описывающих руководства по анализу логистической поддержки (АЛП), электронное документирование, процедуры МТО и ТОиР.
Стандартом установлены сущности и атрибуты (элементы данных - ЭЛД) информационных моделей ИЛП и их отношения в виде словарей и таблиц реляционной БД. Каждый ЭЛД имеет уникальный номер. Таблицы формируются из колонок ЭЛД. Примеры ЭЛД: тип структуры (физическая или функциональная), код организации, номер изделия, вид отказа и др.


Стандарт AECMA S1000D
Спецификация AECMA S1000D — технология представления технической документации, признанная в авиационной промышленности (AECMA — European Association of Aerospace Constructors). Кроме стандартизации перечня информации предметной области стандарт регламентирует определение общей базы данных эксплуатационной документации. Основная цель общей базы данных заключается в предоставлении исходной информации для создания технической публикации. Документация может быть определена как данным стандартом, так и любой другой гражданской или военной спецификацией. База данных также предназначена для использования в электронной логистической информационной системе для передачи информационных модулей напрямую их потребителям (пользователям). Такие модули могут быть также интерактивными. Данный аспект использования отражен в самом названии базы данных — общая база данных эксплуатационной документации. Оно подразумевает, что регламентируемая стандартом информация должна использоваться как производителями, так и покупателями и эксплуатантами военных и гражданских воздушных судов.
В основе AECMA S1000D, как и в старших классах ИЭТР, лежит декомпозиция представляемого материала на модули. Модули включают идентификационную и содержательную секции, записанные на языках SGML или HyTime с иллюстрациями в форматах CGM или JPEG, и хранятся в специальной БД — Common Source Data Base (CSDB). Предусмотрена автоматическая простановка гиперссылок (для этого имеются соответствующие программные средства).
Предусмотрены модули нескольких типов:
  • Описание устройства и принципов работы изделия.
  • Каталог деталей и сборочных единиц.
  • Регламент технического обслуживания. Включает перечень типов работ со ссылками на соответствующие технологические карты.
  • Правила выполнения процедур технического обслуживания.
  • Возможные неисправности и способы их устранения.
  • Инструкции для оператора.


Стандарт AECMA S2000M
Стандарт AECMA S2000M посвящен вопросам материально-технического обеспечения, технического обслуживанния и ремонта в авиационной промышленности. По своему назначению близок к стандарту DEF STAN 00-60. Включает разделы, описывающие планирование МТО, кодификацию, управление заказами, счетами, ремонтом.
В стандарте описаны информационные модели МТО. Для примера часть информационной модели на языке Express-G приведена на рис. 1 (указана лишь часть сущностей и атрибутов).
Рис. 1. Фрагмент модели связи структуры изделия и его МТО


Управление конфигурацией
Управление конфигурацией относится к важнейшим функциям PDM. В соответствии с документом ISO 10007 "Quality management systems — Guidelines for configuration management" конфигурация изделия определяется как совокупность функциональных, эксплуатационных и физических атрибутов изделия. Управление конфигурацией включает выработку требований к основным выходным параметрам (называемых техническими требованиями или нормами этих параметров), сопоставление технических требований и получающихся значений выходных параметров, управление версиями проекта и внесением изменений в проект. Эти процедуры необходимо выполнять для обеспечения целостности проектных данных. Управление конфигурацией актуально также тогда, когда на основе некоторой базовой модели (конструкции) изделия создаются его различные модификации.
Если в проект нужно внести изменения, то создается новая версия проекта, основанная на первоначальном проекте, и изменения вносятся уже в эту новую версию. Исходный вариант проекта при этом сохраняется в прежнем виде. Одна версия каждого объекта является текущей или активной версией. Если имеется несколько версий объекта, то текущей является та, которая последней подвергалась изменениям.
В системе BaanPDM принята следующая схема управления версиями. Если версия объекта создана впервые, ей назначается статус "неопределенная". Если версия объекта готова для общего доступа, ее следует занести в сборник, и затем BaanPDM назначает ей статус "готово к выпуску". Выпуск объекта делает его описание доступным для использования в других подразделениях и производства. Если кто-либо желает сделать изменения в готовой к выпуску версии объекта, он должен извлечь ее из сборника. Этой версии присваивается статус "находящаяся в процессе изменения", который показывает, что готовится новая версия, а новой версии — неопределенный статус.
В некоторых PDM были предусмотрены следующие статусы для версий документов: рабочий — версия c таким статусом находится в работе, ее можно модифицировать; принятый — именно версия с этим статусом является основой для взаимодействия частей проекта, она служит для обмена данными между объектами, ее модификации осуществляются через рабочий статус; архивный — статус, присваиваемый предыдущим сохраняемым версиям; порождаемый — статус зарезервирован для вновь создаваемых объектов, например, при синтезе проектных решений. Разработчик сам изменяет статус объектов.
Аналогично в системе PDM STEP Suite одна из версий проекта является рабочей (активной), с ней работают пользователи. Но можно обращаться и к любой другой версии. В процессе коллективной работы хранимый в БД документ, чертеж или модель могут быть взяты для дальнейшей проработки. Тогда исходная версия документа помечается как находящаяся в процессе редактирования. После редактирования созданная новая версия хранится вместе с предыдущей. При этом для каждой версии документа можно определить породившую ее исходную версию.
В PDM Teamcenter предусмотрены сохранение истории внесения изменений в проект, верификация характеристик изделия после внесения изменений, реализация наследования атрибутов базовой конфигурации и т.п.


Управление проектами
Под управлением проектами подразумевают деятельность, направленную на организацию, планирование и контроль выполнения проектов.
Часто управление крупными проектами, включающее распределение большого числа работ во времени и между исполнителями, выполняется программами, относящимися к специальной группе систем управления проектами. В эту группу входят программы верхнего уровня, такие, как Artemis Project (фирма Metier), Primavera Project Planner (Primavera Systems), Open Plan (Welcom Software), среднего уровня — Time-Line (Symantec), Microsoft Project (Microsoft) и др.
Например, система Project Manager Workbench служит для одновременного управления различными проектами с оптимальным распределением ресурсов, помогает построить иерархическую структуру плана, сформировать несколько видов отчетов, описывающих расписания, расходы, контроль качества. С ее помощью контролируют общее использование ресурсов, составляют расписания разнохарактерных работ. В качестве ресурсов могут рассматриваться люди, финансовые средства, устройства.
Управление проектами (процессом проектирования) входит также в число функций PDM. Проектирование состоит из многих шагов, объединяемых в потоки работ (workflow). Управление потоком работ включает в себя большое число действий и условий, поддерживающих параллельную работу многих пользователей над общим проектом. Необходимо распределить работы как между исполнителями, так и во времени, а также обеспечить контроль выполнения работ.
Шаги заданного или динамически определяемого маршрута работ могут представлять собой выполнение проектных операций и процедур, пересылку документов и файлов другим пользователям, изменение статуса объекта, просмотр, контроль и утверждение инженерных проектов и внесения в них изменений и т.п. Между шагами перемещается пакет документов. На шагах маршрута документы проекта обрабатываются, видоизменяются, оцениваются, пакет автоматически пополняется и, в конечном счете, проектная документация выпускаются в производство.
Системы workflow должны автоматически генерировать предупреждения в случае замедления процесса и указывать место, где он застопорился или замедлился; отражать состояние процесса; предоставлять статистику по процедурам и функциям.
Управление потоком работ выполняется на основе моделей вычислительных процессов. Используются спецификации моделей, принятые в CASE-системах, например, диаграммы потоков данных, ориентированные графы, UML-диаграммы. Сначала модели составляют в терминах проектных заданий, а затем система осуществляет их покрытие имеющимися проектирующими программами и программными модулями. Применяют также описания на языках расширения или 4GL.


Обзор CALS-стандартов
Центральное место в системе CALS-стандартов занимают стандарты, разработанные под эгидой Международной организации стандартизации ISO и получившие название STEP (Standard for Exchange of Product data) и номер 10303. Стандарты ISO 10303 определяют средства описания (моделирования) промышленных изделий на всех стадиях жизненного цикла.
Единообразная форма описаний данных о промышленной продукции обеспечивается введением в STEP языка Express, инвариантного к приложениям. В стандартах STEP использован ряд идей, ранее воплощенных в методиках информационного IDEF1X и функционального IDEF0 проектирования. Но роль стандартов STEP не ограничивается введением только грамматики единого языка обмена данными. В рамках STEP предпринята попытка создания единых информационных моделей (онтологий) целого ряда приложений. Эти модели получили название прикладных протоколов.
Стандарт ISO 10303 состоит из ряда документов (томов), в которых описываются основные принципы STEP, правила языка Express, даны методы его реализации, модели, ресурсы, как общие для приложений, так и некоторые специальные (например, геометрические и топологические модели, описание материалов, процедуры черчения, конечно-элементного анализа и т.п.), прикладные протоколы, отражающие специфику моделей в конкретных предметных областях, методы тестирования моделей и объектов.
Удовлетворению требований создания открытых систем в STEP уделяется основное внимание — специальный раздел посвящен правилам написания файлов обмена данными между разными системами, созданными в рамках STEP-технологии.
Развитие CALS-технологий нашло выражение в разработке серий стандартов ISO 13584 Parts Library (сокращенно P-Lib), ISO 14959 Parametrics, ISO 15531 Manufacturing management data (Mandate), ISO 8879 Standard Generalized Markup Language (SGML). Разработка новых российских CALS-стандартов и изменений к стандартам ЕСКД должна быть увязана со стандартами и проектами стандартов серий ГОСТ Р ИСО 10303 и ГОСТ Р ИСО 13584, являющихся русскоязычными версиями стандартов ISO 10303 и ISO 13584.
Стандарты Parts Library (P-LIB) содержат обзор и основные принципы представления данных о стандартных компонентах промышленных изделий. В этих стандартах представлены в виде библиотек данные о семействах таких типовых широко используемых компонентов изделий, как болты, подшипники, электронные компоненты и т.п., с целью использования этих данных в различных системах автоматизированного проектирования. В P-LIB содержатся также правила использования, интерфейса и модификации библиотечных описаний. Цель стандарта — обеспечить инвариантный для приложений механизм оперирования частями библиотеки.
Благодаря ISO 13584 различные прикладные САПР могут разделять данные из обобщенных баз данных, беспрепятственно обмениваться данными о типовых компонентах. Описание библиотечных моделей дается на языке Express. Для описания структуры частей, вводимых определений и других текстовых фрагментов используется язык SGML. Поведенческие модели электронных компонентов могут быть выражены с помощью языка VHDL.
Стандарты P-LIB состоят из нескольких частей.
Часть 1 содержит обзор и основные принципы серии стандартов.
Часть 10 посвящена концептуальной модели, а часть 24 — логической модели построения библиотек. Библиотеки могут компоноваться из данных от разных поставщиков. В части 26 определяются поставщики библиотек, в части 31 описан программный интерфейс. Описание методологии структуризации семейств содержится в части 42. Протоколам обмена посвящены части, начинающиеся с номера 101. Часть под номером 101 содержит протокол обмена геометрической параметризованной информацией; часть под номером 102 — протокол обмена согласованными с STEP данными.
Стандарты Parametrics введены сравнительно недавно (1996 г.) в связи с тем, что стандарты STEP в недостаточной мере учитывали особенности современных САПР в части представления параметризованных моделей изделий и обмена параметризованными данными.
Рабочая группа ISO по Parametrics решает как краткосрочные, так и перспективные задачи. Первые из них касаются удовлетворения потребностей геометрического проектирования и машинной графики в сегодняшних САПР, в которых широко используются параметризованные модели. Вторые касаются попыток распространения идей параметризации на более ранние этапы проектирования и на более широкий круг моделей и процедур проектирования, имеющих не только геометрический характер.
Стандарты Mandate посвящены представлению данных, относящихся к функционированию предприятий, управлению территориально распределенными производственными системами, обмену данными о производстве с внешней для предприятия средой.
Часть стандарта, обозначаемая ISO 15531-21, содержит обзор и основные принципы представления данных о промышленной продукции. Содержание этой части характеризуется следующими ключевыми словами: системы промышленной автоматизации и интеграция, промышленные данные, обмен данными об управлении производством, обмен данными с внешней средой.
Том ISO 15531-31 посвящен обзору и основным принципам использования данных о производственных ресурсах. Излагаются модель, форма и атрибуты представления данных о производственных ресурсах, об управлении их применением.
Том ISO 15531-41 содержит обзор и основные принципы управления потоками производственных данных.
В рабочей группе WG10 подкомитета SC4 была предпринята попытка разработки стандарта ISO 18876 "Integration of industrial data for exchange, access, and sharing" (IIDEAS). Его назначение — обеспечение взаимодействия приложений и организаций, использующих разные стандарты, интеграция данных и моделей, получаемых из разных источников, разрабатываемых в разных САПР. Предполагалось согласование моделей, выраженных с помощью разных языков моделирования и форматов, например, таких, как SGML, XML, Express. Средства интеграции — специальные интеграционные модели и методы создания, распространения, обновления моделей, их связи с прикладными протоколами. Предполагалось также, что в IIDEAS будет введен язык EXIST (EXpression of Information based on Set Theory), более соверешенный, чем EXPRESS, учитывающий ряд свойств таких языков, как Unified Modelling Language (UML), Knowledge Interchange Format (KIF), XML и др. Некоторые свойства EXIST уже рассматривались рабочей группой WG11 в проекте языка EXPRESS-2. Однако к настоящему времени ISO 18876 так и не появился из-за трудностей реализации проекта.
Оформление технической документации на создаваемые изделия в CALS-технологиях должно выполняться на основе языка разметки SGML (Standard Generalized Markup Language). Этот язык представлен в семействе стандартов ISO 8879 и предназначен для унификации представления текстовой информации в автоматизированных системах.
Стандарт SGML устанавливает такие множества символов и правил для представления информации, которые позволяют различным системам правильно распознавать и идентифицировать эту информацию. Названные множества описывают в отдельной части документа, называемой декларацией DTD (Document Type Decfinition), которую передают вместе с основным SGML-документом. В DTD указывают соответствие символов и их кодов, максимальные длины используемых идентификаторов, способ представления ограничителей для тегов, другие возможные соглашения, синтаксис DTD, а также тип и версию документа. Следовательно, SGML можно назвать метаязыком для семейства конкретных языков разметки. В частности, подмножествами SGML можно считать языки разметки XML и HTML. При этом XML более удобен, чем SGML: легче воспринимается, приспособлен для использования в WWW (современных браузерах), сохраняя возможности SGML. Для конкретных приложений создаются свои варианты (словари) XML. Известны варианты для математики, химии, медицины. Для CALS интерес представляет вариант Product Definition eXchange (PDX), посвященный обмену данными.
Техническое описание в виде SGML-документа включает:
  1. основной файл с техническим руководством, размеченный SGML-тегами;
  2. описание сущностей, если документ относится к группе, в которой используются одни и те же сущности и подразумевается их известность:
  3. словарь для пояснения SGML-тегов;
  4. DTD.
Стандарт MIL-STD-1840C посвящен представлению и обмену данными в CALS-технологиях. Основные положения этого стандарта признаны в России и представлены в документе Р50.1.027-2001. Стандарт определяет международные, национальные, военные стандарты и спецификации для электронного обмена информацией между организациями или системами. В нем к стандартам и спецификациям технологий CALS отнесен ряд стандартов таких, как вышеназванные стандарты STEP, SGML, а также стандарты шифрования данных и электронной подписи, кодирования аудио и видео данных, спецификации MIME электронной почты и т.п.
В соответствии с MIL-STD-1840C документы могут быть SGML-документами, обменными файлами на языке Express, для представления иллюстраций и текста допускается использование ряда других форматов. Так, для передачи и представления в технических руководствах иллюстративного материала (схем, рисунков) в соответствии с американским стандартом MIL-PRF-28003 можно использовать формат BMP, но более экономичен формат JPEG. Для 2D чертежей (но не в САПР) рекомендуется использовать формат CGM (Computer Graphics Metafile), ранее введенный в ISO/IEC 8632. Растеризация выполняется в соответствии с рекомендацией MIL-PRF-28002. Стандартный растровый формат — TIFF. Отметим, что документы MIL-PRF-28000 и MIL-PRF-28001 посвящены соответственно форматам IGES и SGML. Формат IGES (Initial Graphics Exchange Specification), утвержденный в качестве стандарта в начале 80-х годов, был предшественником STEP, но он был ориентированным в основном на описание геометрических свойств изделий.
В структуре документа выделяют реквизитную и содержательную части. В реквизитной части записываются метаданные в виде списка идентификаторов атрибутов и их значений, а также сведения об электронных подписях документа. Содержательная часть состоит из одного или более блоков данных, каждый блок имеет собственно передаваемые данные и их описание.
Электронная цифровая подпись (ЭЦП) представляет собой хэш-функцию передаваемого документа, закодированную составителем документа закрытым ключом по асимметричной схеме. Прочитать ЭЦП можно с помощью открытого ключа, но подделать подпись, не зная закрытого ключа, практически нельзя.
Для унификации структуры документов и правил деловой переписки прежде всего в торговых операциях Организация Объединенных Наций приняла в 1986 г. спецификации EDIFACT (Electronic Data Interchange For Administration, Commerce and Transport). Это международный стандарт (ISO 9735) для представления и обмена электронными данными, которые могут группироваться в сегменты, смысл которых частично описан в стандарте, но может быть обусловлен договоренностью между партнерами.
Спецификация MIL-D-87269 - Interactive Electronic Technical Manual (IETM) Database - описывает требования к создаваемым подрядчиками-поставщиками систем вооружений базам данных для интерактивных электронных технических руководств и справочников. В спецификации содержатся требования к построению баз данных, обеспечению обмена данными, наименованию элементов данных, сопровождению и обслуживанию данных. В приложениях к документу перечислены обязательные и необязательные элементы любой документации, а также их взаимосвязь. Подробно описана схема внутреннего построения баз данных на основе конструкций и элементов языка SGML. Описаны методы представления структуры и состава промышленного изделия и его компонент в языке SGML, а также даны шаблоны документов на обязательные составные части технической документации(такие как информация о неисправностях, техническое описание и т.п.)
Особенности проектирования радиоэлектронной аппаратуры находят отражение и в форматах обмена данными. Основные методики функционального и логического проектирования электронных устройств основаны на использовании языка VHDL (Very high-speed integrated circuits Hardware Design Language), получившего статус международного стандарта IEEE 1076 в 1987 г. При конструкторском проектировании для описания топологии СБИС и печатных плат широко применяются форматы EDIF (Electronic Design Interchange Format) и CIF (Caltech Intermediate Format).
Развитие методологии моделирования на базе языка VHDL привело в 1999 г. к принятию стандарта IEEE 1076.1, посвященного смешанному (mixed mode) моделированию. Отметим, что смешанным принято называть аналого-цифровое моделирование, т.е. исследование моделей, в которых используются как непрерывные, так и дискретные величины. Объединение стнадартов IEEE 1076 и 1076.1 в одном документе VHDL-AMS (VHDL Analog and Mixed Signal) позволило унифицировать описание моделей не только систем электрической природы, но также систем механических, гидравлических, тепловых, а также систем с физически разнородными компонентами.
В CALS-технологиях представлены не только вопросы описания данных и организации информационных обменов, но и вопросы моделирования приложений. Для выполнения начальных шагов моделирования сложных слабоструктурированных приложений рекомендуется использовать методики объектного моделирования на базе языка UML (Unified Modeling Language), функционального моделирования систем IDEF0, информационного моделирования IDEF1X. В частности, методики IDEF0 и IDEF1X представлены в федеральных рекомендациях США соответственно FIPS 183 и FIPS 184.
К CALS-стандартам относят также стандарты интегрированной логистической поддержки изделий и группу стандартов, посвященных созданию интерактивных электронных технических руководств


Структура стандартов STEP
При разработке стандартов STEP были поставлены цели обеспечения единообразного описания и интерпретации данных в автоматизированных системах на различных этапах жизненного цикла изделий. К их разработке стандартов STEP под эгидой ISO был привлечен ряд ведущих компаний и специалистов фирм в разных отраслях промышленности.
Основу STEP составляет язык Express. Это язык унифицированного представления данных и обмена данными в компьютерных средах. Язык инвариантен к приложениям. Хотя он разрабатывался с ориентацией прежде всего на описание жизненных циклов промышленной продукции, области его применения значительно шире.
В STEP используются следующие важные понятия:
  • AAM — Application Activity Model; это функциональная модель IDEF0 для определенного приложения;
  • ARM — Application Requirements Model; это модель, представляющая данные с точки зрения пользователя. В частности, в этой модели данные могут быть выражены как средствами, типичными для приложения, так и с использованием синтаксиса языка Express.
  • AIM — Application Interpreted Model; это ARM модель, переведенная в STEP представление с использованием ряда унифицированных в STEP понятий, закрепленных в интегрированных ресурсах.
  • AP — Application Protocol; это STEP стандарт, отражающий специфику конкретного приложения;
  • SDAI — Standard Data Access Interface; программный интерфейс к базе данных, разделяемой рядом прикладных систем (в том числе CAD/CAM системами) и представленной на языке Express. SDAI представляет собой унифицированный набор процедур доступа к базе данных, используется в STEP средах для организации обменов между приложениями через общую базу данных.
STEP — это совокупность стандартов и состоит из ряда томов. Тома имеют свои номера N и обозначаются как "часть N" или ISO 10303-N. К настоящему времени разработано более сотни томов, часть из них имеет статус проектов, часть уже утверждена в качестве стандартов ISO.
Том 1 (ISO 10303-1) — вводный стандарт, выполняющий роль аннотации всей совокупности томов. В этом стандарте вводится ряд терминов, используемых в других стандартах, например, таких как продукт (product), приложение (application), проектные данные (product data), модель (model), модели AAM, AIM, ARM, прикладной протокол (AP), интегрированный ресурс (integrated resource), элемент функциональности (unit of functionality — UoF).
  • Тома 11- 14 — методы описания (Description methods),
  • Тома 21- 29 — методы реализации (Implementation methods),
  • Тома 31-35 — основы тестирования моделей (Conformance testing methodology and framework),
  • Тома 41- 50 — интегрированные основные ресурсы (Integrated generic resources),
  • Тома 101 -108 — интегрированные прикладные ресурсы (Integrated application resources),
  • Тома 201- 236 — прикладные протоколы (Application protocols),
  • Тома 301- 332 — абстрактные тестовые наборы" (Abstract test suites),
  • Тома 501 — 520 — прикладные компоненты (Application interpreted constructs).
Ряд томов переведен на русский язык и представлен в виде национальных стандартов России. Это, например, ГОСТ Р ИСО 10303-1-99, посвященный обзору и основополагающим принципам STEP, ГОСТ Р ИСО 10303-11-99 — справочное руководство по языку Express, ГОСТ Р ИСО 10303-21-99 — то же по обменному файлу, ГОСТ Р ИСО 10303-41-99 — описание интегрированных родовых ресурсов. Перечисленные документы соответствуют стандартам ISO 10303-1, ISO 10303-11, ISO 10303-21, ISO 10303-41. Подготовлены к утверждению стандарты ГОСТ, соответствующие томам 43, 44, 203 стандарта ISO 10303.
Методы описания
Первая группа документов — тома с номерами в диапазоне с 11 до 19, тома предназначены для описания диалектов языка Express.
N=11: Express (Express language reference manual) - основное руководство по языку Express. Содержит также описания расширения Express-C базового языка и графического варианта языка Express-G. Базовый язык приспособлен для описания и передачи статических свойств объектов приложений, т.е. параметров структур и ограничений. Расширение языка Express-C включает средства описания динамических свойств объектов (добавлено описание событий и транзакций). Для наглядности представления языковых конструкций в Express предусмотрены графические средства изображения моделей, в качестве которых может использоваться специальное дополнение Express-G (графичесский Express). Express-G — язык диаграмм, отдаленно напоминающий язык описания информационных моделей в методике IDEF1X.
N=12: Express-I (Language Reference Manual). Express-I — расширение языка, предназначенное для описания отдельных экземпляров данных.
N=14: Express-X (Mapping and view language) - промежуточный язык, аналогичный Express-M и используемый для описания соответствий между типами данных в заданной исходной Express-схеме и создаваемыми новыми ее вариантами (views); в качестве views могут использоваться форматы с описанием того же множества сущностей, что и в Express-схеме, например, формат IGES.
Разрабатываются также дополнения, относящиеся к следующим диалектам языка:
Express-M: Mapping definition language; язык и Express-X служит для описания соответствий между сущностями и атрибутами некоторых моделей, представленных в виде схем на языке Express. Например, этими схемами могут быть два разных прикладных протокола, имеющих частично общие данные, или две схемы одного приложения, но созданные разными лицами (при отсутствии соответствующего AP).
В Express-X и Express-M одна схема есть схема-источник, другая — целевая схема. Целевых схем может быть несколько при одной схеме-источнике. Предложения Express-X (Express-M) транслируются на язык C, результирующая программа представляет собой совокупность обращений к функциям базы данных SDAI в STEP-среде. Другими словами, транслятор относится к системе SDAI (см. протокол ISO10303-22), а Express-X можно рассматривать, как язык 4GL для обращений к функциям базы данных SDAI.
Express-P (Process definition language) - язык диаграмм для представления процессов, методов и коммуникационных структур.
Express-V - язык, предназначенный для получения ARM представлений из AIM моделей, другими словами, для описания процедур поиска экземпляров Express-объектов, отвечающих заданным условиям, и доступа к ним, например, при создании новых ARM. Эти создаваемые ARM-представления обычно не требуют столь всестороннего описания приложения, как в AIM, и потому могут быть существенно проще. В Express-V имеются:
  1. схема-источник (AIM), обычно это прикладной протокол, например, AP203;
  2. схема-цель, задающая сущности, которые должны быть в создаваемой частной модели;
  3. схема отображения нужных сущностей из источника в цель. На языке Express-V описываются условия (в виде клозов WHEN) такого отображения. берется подходящая уже существующая AIM, как источник, все совпадающие объекты переводятся в ARM, далее описываются оригинальные объекты. Дополнительной возможностью реализаций Express-V является обратное отображение специфики создаваемой ARM в исходную AIM с целью развития прикладных протоколов.
Для возможности применения языка Express должны быть разработаны методы реализации (Implementation Methods), которые могут быть представлены средствами файлового взаимодействия, построением БД, интерфейсом с языками программирования.
Методы реализации
Вторую группу (тома с номерами 21...29) называют "Методы реализации", она служит для реализации межпрограммного информационного обмена между прикладными системами в STEP-среде. Предусмотрены межпрограммные связи с помощью обменного файла и доступа к БД.
N=21: Clear Text Encoding of the Exchange Structure (physical transfer file format); стандарт устанавливает правила оформления обменного файла. Обменный файл играет в STEP важную роль; если собственно на языке Express определены сущности, то именно в обменном файле задаются экземпляры этих сущностей. Прикладные программы для связи со STEP средой должны читать и генерировать обменные файлы.
N=22: Standard Data Access Interface Specification; содержит описание SDAI — системы представления данных и доступа к данным конкретных прикладных систем (чаще всего это CAD/CAM системы). Данные, участвующие в межпрограммных связях, образуют SDAI-модели. В системе SDAI предусматривается компилятор кода, конвертирующего эти модели в SDAI базу данных, а также функции обращения к этой базе данных. Возможно непосредственное построение прикладных систем, работающих с SDAI базой данных.
Тома с номерами N = 23...29 устанавливают правила обращения к данным в SDAI базе данных на языках программирования C++, C, Java, на языке моделирования UML на языке передачи данных в системах распределенных вычислений IDL, языке разметки XML.
Остальные тома стандарта ISO 10303 посвящены описанию тестирования моделей, представленных на языке Express, интегрированным ресурсам, прикладным протоколам и прикладным компонентам.


Структура моделей на языке Express
Базовый для STEP-технологий язык Express описан в стандарте ISO 10303, том 11. Язык является объектно-ориентированным, имеет универсальный характер, его можно использовать для описания статических структур и их свойств в различных предметных областях, несмотря на то, что язык разрабатывался прежде всего в качестве средства представления моделей промышленных изделий на разных этапах их жизненного цикла.
Описание некоторого приложения на языке Express в рамках стандартов STEP называют Express моделью (мodel). В модели декларируются множества понятий и объектов, входящих в приложение, свойства и взаимосвязи объектов.
Модель состоит из одной или нескольких частей, называемых Express схемами (schema) или просто схемами, и обменного файла. Схема — раздел описания, являющийся областью определения данных. В ней вводятся необходимые типы данных. При описании свойств типов данных могут применяться средства процедурного описания — процедуры, функции, правила, константы. Обменный файл содержит конкретные экземпляры типов данных.
Описание схемы начинается с заголовка, состоящего из служебного слова schema и идентификатора — имени схемы. Далее следует содержательная часть — тело схемы. Описание заканчивается служебным словом end_schema:
SCHEMA <имя_схемы>;
<тело_схемы>;
END_SCHEMA;
В языке Express-G схема представляется прямоугольником с разделительной горизонтальной линией, над этой линией записывается имя схемы, как это показано на рис. 1.
Рис. 1. Изображение схемы в языке Express-G
Для установления интерфейса между двумя схемами вводятся спецификации интерфейса. Применяют два типа спецификаций — use и reference. Например:
SCHEMA s1;
ENTITY par1;
name: STRING;
END_ENTITY;
END_SCHEMA;
SCHEMA s2; ( * в схеме s2 в качестве параметра х используется name из
 s1.par1 *)
USE FROM s1.par1 (name AS x);
END_SCHEMA;
Ссылки типа use отличаются тем, что декларации сущностей из другой схемы используются в данной схеме как свои локальные, в то время как reference просто позволяет обращаться к декларациям другой сущности. Ограниченность reference выражается в том, что сущности из другой схемы можно использовать только в качестве типов атрибутов в сущностях данной схемы.
В языке Express-G используются диаграммы двух уровней. На схемном уровне (schema level) изображаются схемы и их взаимосвязи в виде линий. На сущностном уровне (entity level) изображаются типы, сущности, атрибуты, а для ссылок на объекты другой схемы применяются специальные символы.
Эти символы представляют овальными фигурами. В овале записывают имя схемы-источника и имя используемого определения. В нашем примере это ссылка на s1.par1. Овал помещается внутрь прямоугольника, в котором дополнительно указывается имя атрибута (в примере это name).
Для указания межстраничной связи, что требуется, если Express-G модель размещается более чем на одной странице, используется овальный символ, внутри которого указываются через запятую номер страницы и номер ссылки.


Организация в STEP информационных обменов
Обменные файлы (STEP-файлы) служат для передачи данных из одной автоматизированной системы в другую.
Очевидно, что обе взаимодействующие системы должны поддерживать один и тот же формат представления данных в обменном файле. В MCAD обменные файлы в основном содержат информацию о чертежах и геометрических моделях изделий.
Наибольшее распространение в MCAD получили форматы IGES (стандарт ANSI), DXF (стандарт де факто, разработанный в компании Autodesk), формат STEP (стандарт ISO 10303.21).
В файле стандарта IGES имеется заголовочная и основная части. В основной части имеется возможность описывать точки, линии, поверхности и (начиная с версии 4.0) твердые тела.
В файле формата DXF имеются раздел для описания всех элементов кодируемого чертежа, блок команд, аналогичный дисплейному файлу, а также заголовок и описание типов элементов, стилей текста и т.п.
В среде STEP возможны обмены через обменный файл и через базу данных SDAI.
Для обмена конкретными значениями атрибутов в STEP введен обменный файл (протокол ISO 10303-21). Файл состоит из головной и информационной секций. В головной секции (между служебными словами HEADER и ENDSEC) указываются:
  • Entity file_name — имя и некоторые другие атрибуты данного конкретного обменного файла;
  • Entity file_description — неформальное описание содержимого файла и требования к ПО для обработки данного файла;
  • Entity file_schema — схемы, для которых далее даны экземпляры сущностей;
  • keyword (список типов).
В информационной секции (между словами DATA и ENDSEC) указываются имена экземпляров сущностей и значения их атрибутов в виде следующих строк:
#1 = POINT(0.0,0.2,0.5);
(* экземпляр сущности типа POINT с именем 1, значения параметров 0, 0.2 и 0.5 типа REAL *)
#2 = WIDGET(.RED.);
(* экземпляр сущности типа WIDGET с именем 2, значение перечислимого типа RED *)
...
#8 = LINE(#1,#4);
(* значениями атрибутов являются экземпляры сущностей с именами 1 и 4 *)
В списке параметров значения перечисляются в том же порядке, в каком они фигурировали в описании сущности.
Пример 1
Express-схема, описывающая геометрию простой фигуры рис. 1:
SCHEMA detail;
ENTITY line;
p1,p2: point;
END_ENTITY;
ENTITY circle;
p1: point;
r: REAL;
END_ENTITY;
ENTITY point;
x,y: REAL;
END_ENTITY;
END_SCHEMA;
Обменный файл получен в следующем виде:
ISO-10303-21;
HEADER;
FILE_DESCRIPTION((),'2;1');
FILE_NAME('model_1','2006-02-26T15:27:12',('ANONYMOUS USER'),('ANONYMOUS ORGANISATION'),
   'EXPRESS Data Manager version 20050406',$,$);
FILE_SCHEMA(('DETAIL'));
ENDSEC;

DATA;
#1= POINT(0.,0.);
#2= POINT(30.,0.);
#3= POINT(0.,16.);
#4= POINT(30.,16.);
#5= POINT(18.,9.);
#6= LINE(#1,#2);
#7= LINE(#1,#3);
#8= LINE(#2,#4);
#9= LINE(#3,#4);
#10= CIRCLE(#5,5.);
ENDSEC;

END-ISO-10303-21;
Рис. 1.
Обменный файл используется также при связи двух систем A и B, имеющих общие данные с различными обозначениями. Пользователь должен написать перекодировщик (например, на языке Express-X), с помощью которого отождествляются идентификаторы одних и тех же сущностей, имевших разные обозначения в схемах A и B.
Связь через интерфейс SDAI отличается от способа обменных файлов тем, что здесь имеет место не просто обмен, а разделение данных многими пользователями, и SDAI фактически выступает в роли метамодели для разных САПР. Другими словами, SDAI представляет собой интерфейс, содержащий набор функций на языках программирования, для доступа к разделяемым моделям, которые могут быть представлены в виде обменного файла.
Способ доступа к STEP-файлам называют связыванием. Различают раннее и позднее связывание.
При раннем связывании в язык программирования вводят описания классов (или функций), соответствующих конкретным сущностям языка Express. Очевидно, что при этом интерфейс жестко привязан к конкретным Express-схемам.
Более универсален способ позднего связывания. В язык программирования вводят функции, с помощью которых можно обращаться к любым экземплярам определенного типа. Конкретные имена сущностей, атрибутов, их экземпляров входят в число параметров функций.
В ECAD для обмена данными о моделях функционально-логического уровня используют языки VHDL, Veriilog, данные для конструкторского проектирования (списки цепей) представляют в формате EDIF (Electronic Design Interchange Format), ряд форматов разработан для передачи результатов топологического проектирования интегральных схем на генераторы изображений для изготовления фотошаблонов.


Интегрированные ресурсы в STEP
В прикладных протоколах широко используются типовые фрагменты информационных моделей, встречающиеся более чем в одном приложении. Эти фрагменты называют интегрированными общими и прикладными ресурсами.
Четвертая группа стандартов STEP (тома с номерами 41...50) "Интегрированные общие ресурсы" описывает общие для приложений части моделей.
Тома с номерами 101 по 199 отведены для документов, относящихся к более специальным средствам, называемым интегрированными прикладными ресурсами (Integrated application resources).
Группа стандартов с номерами, начинающимися с N=501, служит для описания данных о геометрических элементах и моделях некоторых конкретных типовых объектов и конструкций, часто используемых в ряде интегрированных ресурсов и прикладных протоколов. Например, описания геометрических объектов в виде форм Безье или B-сплайнов могут использоваться во многих прикладных протоколах. Поэтому подобные общие описания вынесены в группу прикладных компонентов.
Ниже приведены краткие сведения об основных протоколах STEP, описывающих интегрированные ресурсы и прикладные компоненты.
  • N=41: Fundamentals of product description and support; основы описания и поддержки изделий. В протоколе определяются такие понятия и группы сущностей, как продукт, представление формы (shape_representation), операция (action), контекст — аспект описания (application and product context), статус утверждения (approval), контракт, дата, типы документов, исполнители (организации и персоналии), единицы измерения длин, площадей, масс, температур и др.
  • N=42: Geometric and topological representation; представление геометрии и топологии. В стандарте определен ряд сущностей, их набор близок к набору, используемому в таком стандарте, как IGES. В частности, используются следующие понятия: положение координатной оси (axis_placement), модели кривых в форме B-сплайна (b_spline_curve) и Безье (bezier_curve), модели поверхности в форме B-сплайна (b_spline_surface), рационального B-сплайна (rational_b_spline_surface) и Безье (bezier_surface), точка в декартовых координатах (cartesian_point), преобразование декартовых координат (cartesian_transformation_operator_3d), геометрический аспект (geometric_representation_context), полигональная поверхность (offset_surface), поверхность вращения (surface_of_revolution) и др.
  • N=43: Representation structures; представление структур. Средства описания аспектов документации, ее атрибутов, составных частей и т.п.
  • N=44: Product structure configuration; конфигурация структуры изделий.
  • N=45: Materials; представлены свойства материалов.
  • N=46: Visual Presentation; визуализация. Стандарт построен на базе положений, ранее принятых в стандартах GKS (Graphic Kernel System) и PHIGS (Programmer's Hierarchical Interactive Graphic System). Вводятся группы терминов, относящихся к представлению (presentation), визуализации (visualization), цвету и др.
  • N=47: Shape variation tolerance; допуски.
  • N=48: Form features; свойства форм.
  • N=49: Process structure and properties; структура процессов и свойства.
  • N=101: Draughting; определяются сущности, относящиеся к процедурам черчения.
  • N=104: Finite element analysis; анализ по методу конечных элементов. Описание стандарта на языке Express состоит из нескольких схем. В одной из них задаются геометрические аспекты модели. Здесь описываются следующие типы данных: система координат (декартова, цилиндрическая, сферическая); виды конечных элементов (объемный, поверхностный 2D или 3D, участок 2D или 3D кривой), форма элемента (линейный, квадратичный, кубический); степень свободы; параметры и дескрипторы элементов, позиция элемента, свойства элементов (например, масса, момент инерции, жесткость), материал и его свойства (плотность, эластичность, тепловое расширение), группа элементов и др. В другой схеме основное внимание уделено математическим представлениям. Например, здесь фигурируют такие сущности и типы данных, как тензоры; переменные, характеризующие напряжения; приложенные нагрузки; погрешности; шаги анализа и т.п.
  • N=105: Kinematics; кинематика.
  • N=106: Building construction core model; основная модель строительных конструкций.
  • N=107: Engineering analysis core ARM; ядро инженерного анализа.
  • N=501: Edge-based wireframe; каркасная модель на основе граней.
  • N=502: Shell-based wireframe; каркасная модель на основе оболочек.
  • N=503 (CD): Geometrically bounded 2D wireframe; 2D каркасная модель с геометрически заданными границами.
  • N=504: Draughting annotation; чертежные аннотации.
  • N=506: Draughting elements; чертежные элементы.
  • N=507: Application interpreted construct: Geometrically bounded surface; геометрически ограниченные поверхности.
  • N=508: Application interpreted construct: Non-manifold surface — Поверхности,описанные не в-BREPS-форме.
  • N=509: Application interpreted construct: Manifold surface — BREPS-поверхности.
  • N=510: Geometrically bounded wireframe; геометрически ограниченная модель поверхности.
  • N=511: Topologically bounded surface; топологически ограниченная модель поверхности.
  • N=512: Faceted boundary representation; полигональное представление поверхностей деталей.
  • N=515: Constructive solid geometry; конструктивная геометрия.


Прикладные протоколы STEP
Прикладные протоколы, вводимые в стандартах STEP, создаются для однозначного понимания спецификаций приложений разными пользователями информационных моделей.
Прикладным протоколом в STEP называют информационную модель определенного приложения, которая описывает с высокой степенью полноты множество сущностей, имеющихся в приложении, вместе с их атрибутами, и выражена средствами языка Express. Предполагается, что эта модель содержит в себе описание данных любой конкретной задачи соответствующего приложения, т.е. практические информационные модели прикладных задач оказываются частными случаями прикладных протоколов. Другими словами, прикладной протокол выражает онтологию приложения, поскольку под онтологией понимают совокупность концепций, объектов, отношений и ограничений, выражающих семантику определенной предметной области.
Прикладные протоколы в стандарте ISO 10303 содержатся в томах, начиная с N=201. Прикладные протоколы принято обозначать аббревиатурой AP с указанием номера, например, AP203, AP214. Для связи прикладной системы со STEP используемые ею данные должны быть описаны в соответствующем AP.
Как правило, прикладной протокол включает большое число сущностей и их атрибутов, описания AP составляют десятки страниц на языке Express или десятки рисунков на языке Express-G. Поэтому целесообразно использовать приемы группирования тесно взаимосвязанных сущностей для более лаконичной характеристики AP. Такими группами являются единицы функциональности (UoF — Units of Functionality). Используют также понятие классов (CC — Conformance Classes) для классификации используемых моделей.
Ниже дана краткая характеристика большинства имеющихся к настоящему времени прикладных протоколов. Их число может расширяться за счет разработки новых протоколов.
AP201. Explicit draughting; явное черчение. При использовании протокола оперируют такими понятиями, как структура чертежа, аннотация, геометрическая форма детали, группирование. В число сущностей входят спецификация, утверждение, номер листа, организация-исполнитель, слой, вид и т.п.
AP202. Associative draughting; ассоциативное черчение. Протокол, относящийся к описанию конструкторской документации. В протоколе фигурируют данные, в значительной мере пересекающиеся с данными протокола AP201 и сгруппированные по UoF следующим образом:
  1. структура документации (иерархия, заголовки, утверждающие подписи);
  2. связь с изделием (версия, изготовитель);
  3. аннотация формы изделия (2D или 3D CAD-модель);
  4. связь модели с ее визуализацией (масштаб);
  5. форма аннотации (месторасположение аннотации, символы, заполняемые позиции);
  6. оформление документов (шрифты, цвета);
  7. размеры (допуски);
  8. группирование деталей по тем или иным признакам.
AP203. Configuration controlled design; проектирование с управляемой конфигурацией. Это один из важнейших прикладных протоколов. В нем унифицированы геометрические модели, атрибуты и спецификации: сборок; 3D поверхностей, разделенных на несколько классов; параметры управления версиями и внесением изменений в документацию и др.
Описание протокола AP203 на языке Express представляет собой схему, в которой можно выделить следующие части:
  1. ссылки на заимствованные из стандартов ISO 10303-41, 42 и 44 интегрированные ресурсы. Это ссылки на такие сущности, как контексты приложения и продукции, свойства изделий, массо-габаритные характеристики, расположение координатных осей, типы кривых и поверхностей, указатели статуса контракта, предприятия, исполнителей, даты и т.п.;
  2. описания некоторых обобщенных типов, объединяющих с помощью оператора SELECT ряд частных типов;
  3. описания сущностей, выражающих конструкции изделий. Представлены 6 классов геометрических моделей. Класс 1 предназначен для задания состава изделий без описания геометрических форм. Класс 2 включает каркасные модели с явным описанием границ, например, в виде координат точек и определяемых с их помощью линий. В классе 3 каркасные модели дополнены топологической информацией, т.е. данными о том, как поверхности, линии или точки связаны друг с другом. Класс 4 служит для описания поверхностей произвольной формы. Классы 5 и 6 включают твердотельные модели, так называемые BREP (Boundary representation). К первому из них относятся тела, границы которых аппроксимированы полигональными (фасеточными) поверхностями, состоящими из плоских участков. В классе 6 поверхности, ограничивающие тела, могут быть как элементарными (плоскими, квадратичными, тороидальными), так и представленными моделями в форме Безье, B-сплайнов и др.;
  4. описание других используемых сущностей, относящихся к конфигурации изделия, например, таких как вносимое в проект изменение с соответствующими атрибутами.
AP204. Mechanical design using boundary representation; конструирование механических деталей на основе твердотельной модели. В протоколе введены такие сущности, как имя изделия, шифр, версия, сборочный узел, модель (элементарная, фасеточная или универсальная BREP-модель), цвет, ширина линий представления и т.п.
AP205. Mechanical design using surface representation; конструирование механических деталей на основе поверхностной модели. Ряд понятий, используемых в этом протоколе, аналогичен понятиям протокола AP204, но используются поверхностные модели с границами, представленными геометрически или топологически.
AP207. Sheet metal die planning and design; проектирование штампов для листовой штамповки.
AP208. Life cycle management — Change process; управление процессами изменений в жизненном цикле (управление конфигурацией). Включает идентификацию фактов (недостатков), требующих внесения изменений, их причин, определяет действия по устранению недостатков и лиц, вносящих изменения.
AP209. Composite and metallic structural analysis and related design; анализ композитных и металлических конструкций; комбинирование данных геометрии и управления конфигурацией с данными для анализа, например, по методу конечных элементов. Поддерживаются статический и частотный анализ, 3D сеточные модели для анализа по МКЭ, вводятся определения свойств сборок, средства для представления свойств композитных и однородных материалов.
AP210. Electronic assembly, interconnect and packaging design; компоновка и проектирование межсоединений в электронной аппаратуре, управление конфигурацией и представление данных о печатных платах и сборках при их проектировании и при передаче данных на производственную стадию. В протоколе используются данные о форме и материале изделия, размещении компонентов и имеющихся ограничениях, проводящих и изолирующих слоях, вносимых изменениях в проект и т.д.
AP211. PCA Integrated Diagnositics and test; тестирование и диагностика электронной аппаратуры.
AP212. Electrotechnical design and installation; проектирование и монтаж электротехнических изделий. В протоколе описываются электротехнические системы на стадиях проектирования, монтажа, поставки. Имеются средства для представления функциональной декомпозиции систем, физического размещения оборудования и кабельных соединений, информационного обмена между частями систем, документирования, управления конфигурацией и др. (Но в протоколе не рассматриваются вопросы изготовления, моделирования, тестирования аппаратуры). Примеры используемых в стандарте объектов: электротехнические системы и приборы, функциональный продукт, место размещения (installation location), сигнал, терминал, проект, контракт, интерфейс, цепь, соединение (connectivity), порт. Отдельную группу составляют объекты, представляемые графически, и др.
В протоколе описывается ряд опций, которые могут быть использованы в моделях. Состав этих опций зависит от класса формы. Всего в протоколе 4 класса (CC — conformance classes):
  1. CC1 — проектные данные (классификация, конфигурация, документация с двумерными схемами, структура) без функциональных аспектов и инсталляции;
  2. CC2 — класс 1 с добавлением функциональной информации (распределение функций между частями системы, информационные потоки и др.);
  3. CC3 — класс 1 с информацией об инсталляции (двумерные чертежи с геометрической и пространственной информацией, схемы размещения оборудования);
  4. CC4 — полная совокупность данных — единиц функциональности протокола AP212, т.е. объединение CC1, CC2 и CC3.
AP213. Numerical control process plans for machined parts; проектирование обработки на оборудовании с числовым программным управлением. В протоколе введены средства для описания производственных операций, технологического оборудования и инструментов, материалов, геометрических форм и допусков изделий, рабочих мест, сопроводительных административных данных.
AP214. Core Data for Automotive Mechanical Design Processes; основные данные для проектирования механических частей автомобилей. Имеются средства для представления данных по структуре и геометрии изделий, презентации проектов, моделированию, производственным процессам (числовое управление, допуски, материалы) и др.
В стандарте введено 19 классов моделей (Conformance Classes), классы различаются видом модели (поверхностная, твердотельная, каркасная), наличием данных по кинематике, допускам, управлению конфигурацией.
Геометрические группы родственных понятий (сущностей, атрибутов), фигурирующих в приложении, сведены в AP214 в несколько UoF, имеющих непустые пересечения. Это:
  • G1: wireframe model 2d, включающая такие сущности, как геометрическая модель, точка, линия, кривая, гипербола, B-сплайн, 2D каркасная модель и др.;
  • G2: wireframe model 3d с аналогичными сущностями, но в пространстве 3D;
  • G3: connected surface model, предназначена для представления топологически ограниченных поверхностных моделей, эта группа включает ряд сущностей из G2 и G8 и таких, как кривая или точка на поверхности, цилиндрическая и тороидальная поверхности, конструктивная геометрия и др.;
  • G4: faceted b rep model, относится к BREP моделям с деталями, имеющими планарные поверхности и внутренние пустоты. Понятия точки, линии, плоскости взято из G3 и G5, другие сущности — замкнутая фасеточная оболочка, твердотельное BREP многообразие (manifold solid B-rep) и др.;
  • G5: b rep model — представление одного или более тел, каждое из которых состоит из замкнутых внешней и внутренних оболочек. Геометрия поверхностей выражена кривыми. Большинство понятий аналогично используемым в G3;
  • G6: compound model — модели поверхностные, твердотельные, каркасные с топологически представленными соединениями. Примеры использования: выделение в телах зон с различными свойствами, частей сварной конструкции и т.п.;
  • G7: csg model, или более полное название solid model using Constructive Solid Geometry — получение модели с помощью булевых операций над заданными телами. Наряду с понятиями из предыдущих UoF здесь фигурируют понятия блок, примитив, результат булевой операции и др.;
  • G8: geometrically bounded surface model UoF — геометрически ограниченная поверхностная модель.
Среди других UoF можно отметить:
  • S2: element structure — элементы структуры и аннотаций структуры, например, слой, образец, аспект формы, преобразование 2D или 3D, точность, расположение осей и т.п.;
  • S5: work management с такими сущностями, как операция, метод операции, контракт, порядок работ, изменение;
  • S6: classification с понятиями классификации атрибутов и систем, иерархии и пунктов классификаций;
  • S7: specification control — управление спецификациями предназначено для описания свойств продуктов, имеющих большое число вариантов. Описываются классы продуктов, категории характеристик, способы декомпозиции продукции, ее функции, вводятся сущности конфигурация, проектное ограничение, проектное решение, пункт решения, вариант размещения, спецификация и т.п.
AP215. Ship arrangement: расположение частей судна. Затрагиваются такие аспекты, как декомпозиция на пространственно выделенные части (например, грузовые отсеки, машинное отделение, каюты, переборки), форма корпуса, водоизмещение и т.п.
AP216. Ship moulded form; форма судна. Описываются общие характеристики, размеры, гидростатика, протяженные внутренние поверхности, геометрия надстроек.
AP217. Ship piping; система судовых трубопроводов. Протокол относится к геометрии трубопроводов, их прочности, материалам, анализу потоков, управлению конфигурацией при их проектировании.
AP218. Ship structures; устройство судна. В этом приложении рассматриваются характеристики внутреннего устройства судна.
AP220. PCA Manufacturing Planning; производство печатных плат и сборок. Вводятся средства для представления 2D геометрии размещения компонентов, допусков, операций изготовления, измерения и т.п.
AP221. Functional data and their schematic representation for process plant; функциональная модель и ее схемное представление для производственных процессов. Протокол предназначен для описания иерархического построения предприятий химического, нефтеперерабатывающего производства, атомной энергетики. Рассматриваются состав оборудования, система трубопроводов, характеристики потоков в них.
AP223. Exchange of design and manufacturing product information for casting parts; обмен проектными и технологическими данными для литейного производства. В протоколе предусмотрены следующие аспекты приложения: литье в песчаные формы, моделирование процессов литья, литейное оборудование и материалы, процессы плавления, заливки, охлаждения, экстракции, контроль и тестирование.
AP224. Mechanical product definition for process plans using machining features; описание механических деталей для планирования станочной обработки. Имеются средства для описания особенностей конструкции деталей (например, отверстий, бобышек, буртов), требований к качеству . обработки, свойств материалов, геометрической формы и др.
AP224. Mechanical product definition for process plans using machining features; описание механических деталей для планирования станочной обработки. Имеются средства для описания особенностей конструкции деталей (например, отверстий, бобышек, буртов), требований к качеству обработки, свойств материалов, геометрической формы и др. В протоколе выделены следующие основные единицы функциональности: особенности объекта обработки и свойства обрабатываемых заготовок (UoF включает такие сущности, как выступы, фаски, отверстия, путь обработки, параметры материала, обрабатываемой поверхности, процесса и др.), характеристики обработки (сущности, задающие форму и размеры материала, удаляемого при обработке), допуски на контролируемые параметры, характеристики профиля (сущности, позволяющие по 2D профилям получать 3D формы), управляющая документация (например, требования заказчика, порядок использования ресурсов), внесение исправлений в документацию, административные данные (автор, организация, утверждение), реквизиты (описание заказа на необходимые производственные ресурсы).
AP225. Building elements using explicit shape representation; элементы строительных конструкций с явным представлением их формы.
AP226. Ship mechanical systems; корабельное механическое оборудование. С помощью определений этого протокола описываются силовые установки, электрогенераторы, насосы, компрессоры, соединения компонентов, их функции, параметры шума и вибраций и т.п.
AP227. Plant spatial configuration; пространственная конфигурация предприятий.
AP228. Building services: Heating, ventilation, and air conditioning; инженерные службы в строительстве — теплоснабжение, вентиляция, кондиционирование воздуха.
AP231. Process design and process specifications of major equipment; проектирование и описание основного оборудования. Протокол относится к концептуальному проектированию, контролю, моделированию, материалам оборудования предприятий химической и нефтегазовой промышленности.
AP232. Technical data packaging core information and exchange; представление и обмен технических данных. Протокол посвящен взаимодействию систем управления данными разных проектирующих систем. Объектами описания служат проектные данные как выраженные средствами прикладных протоколов, так и не соответствующие стандартам STEP. Это чертежи, программы для оборудования с ЧПУ, модели проектируемых объектов, спецификации, бизнес-документация и др.
AP233. Systems engineering data representation — системы представления инженерных данных. Имеются в виду данные (единицы функциональности), характеризующие состояния системы и ее параметры (например, цена, производительность, надежность, технологичность, контролепригодность и т.п.), связанные с требованиями к продукту, его функциональной архитектурой, поведением, управлением конфигурацией. Рассматриваются как количественные, так и лингвистические (в том числе нечеткие) переменные вместе с единицами измерения.


Express-X
Семантически эквивалентные прикладные объекты и элементы могут фигурировать в разных моделях. Естественно, что авторы этих моделей, работающие независимо друг от друга, могут использовать разные средства для их описания (например, разные идентификаторы). Если же независимо созданные модели потребуется использовать совместно и соединить в некоторой общей модели, то необходимо описать имеющиеся соответствия параметров. Для таких описаний разработан язык Express-X, вошедший в качестве стандарта ISO 10303-14 в лингвистическое обеспечение STEP.
Приводимый ниже пример характеризует способ установления соответствия между сущностями и атрибутами двух моделей на языке Express.
SCHEMA  Old_data;
  ENTITY Metadata;
    faculty : STRING;
    lecturer : STRING;
    volume : STRING;
    annotation  : STRING;
  END_ENTITY;
  ENTITY Subject;
    name : STRING;
    info: Metadata;
  END_ENTITY;
END_SCHEMA;

SCHEMA  New_data;
  ENTITY Course;
    title : STRING;
    tutor : STRING;
    preface : STRING;
  END_ENTITY;
END_SCHEMA;

SCHEMA_Map Data_Mapping;
  GLOBAL
    DECLARE source INSTANCE OF SOURCE_SCHEMA  Old_data;
    DECLARE target INSTANCE OF TARGET_SCHEMA  New_data;
  END_GLOBAL;
  MAP lecture FOR tgtInstance:target::Course;
    FROM (srcInstance:source::Subject)WHEN TRUE;
    BEGIN_MAP
      tgtInstance.title := srcInstance.name;
      tgtInstance.tutor := srcInstance.info.lecturer;
      tgtInstance.preface := srcInstance.info.annotation;
    END_MAP;
END_SCHEMA_MAP;


Типы данных в языке Express
В теле схемы декларируются типы данных (Data Type). Тип данных — это множество значений некоторой величины или множество объектов (набор экземпляров). В языке Express используются следующие типы данных: сущность (Entity), простой (Simple Type), агрегативный (Aggregation Data Type), определяемый (Defined Data Type), нечисловой (Enumeration Data Type) и выделяемый (Select Data Type) типы.
Сущность — тип данных, представляющий набор концептуальных или реальных физических объектов с некоторыми общими свойствами. Сущности используют для описания объектов приложений. Свойства сущности выражают в виде атрибутов (Attributes). К характеристикам сущностей относятся также ограничения, накладываемые на значения атрибутов или на отношения между атрибутами.
Описание сущности начинается со служебного слова ENTITY, за которым следуют идентификатор сущности, описания ее атрибутов и возможно также правил. Каждый из атрибутов представлен его идентификатором и типом:
ENTITY <имя_сущности>;
<идентификатор_атрибута>:<тип_атрибута>;
...
END_ENTITY;
Например, задание прямой линии (line) в виде двух инцидентных точек р0 и р1 (атрибутов типа point) выглядит следующим образом:
ENTITY line;
p0,p1: point;
END_ENTITY;
Атрибуты и переменные сами могут быть сущностями, так тип атрибутов p0 и p1 предыдущего примера декларируется, как сущность, атрибутами которой в случае пространства 3D являются геометрические координаты x,y,z:
ENTITY point;
x,y,z: REAL;
END_ENTITY;
В языке Express-G сущности изображаются прямоугольниками, внутри прямоугольника записывается имя сущности (рис. 1).
Рис. 1. Изображение сущности в языке Express-G
Если свойство является необязательным для данной сущности, то его выражают так называемым необязательным (optional) атрибутом. В его описании перед типом атрибута добавляется служебное слово OPTIONAL:
<идентификатор_атрибута>: OPTIONAL <тип_атрибута>;
Изображение атрибутов в Express-G поясняет рис. 2, из которого, в частности, следует, что атрибут представлен прямоугольником, а связи "сущность-атрибут" или "сущность-сущность" отображаются линиями, причем в случае связи с optional атрибутом используется пунктирная линия. Направление связи обозначается окружностью на конце линии, ведущей к атрибуту. Имя атрибута записывается рядом с этой линией. В прямоугольнике атрибута записывается тип атрибута.
Рис. 2. Изображение атрибутов в языке Express-G
Некоторые из атрибутов могут определяться через другие атрибуты. Тогда атрибуты, выражаемые через другие атрибуты, называют порожденными (derived), что отображается служебным словом derive в декларации атрибута. Например, описание окружности, кроме обязательных атрибутов, которыми в нижеследующем примере выбраны радиус и центр окружности, может включать порожденный атрибут площадь круга:
ENTITY point;
x,y,z: REAL;
END_ENTITY;
ENTITY circle;
center: point;
radius: REAL;
DERIVE
area: REAL := pi*radius**2;
END_ENTITY;
В этом примере использованы явные атрибуты center, radius и порожденный атрибут area.
Отметим, что между символами (* и *) записывается комментарий — произвольный текст по усмотрению автора модели. Если комментарий умещается в одной строчке, то достаточно перед его текстом поставить двойной дефис ( -- ).
К простым типам данных относятся следующие типы:
  • integer — целые числа;
  • real — вещественные числа;
  • number — тип, объединяющий типы integer и real;
  • logical — его значениями могут быть true, false или unknown (неопределенность);
  • Boolean — с возможными значениями true или false;
  • binary — последовательность битов 1 или 0;
  • string — строка символов.
Рис. 3. Изображения простых типов в языке Express-G
Изображения простых типов на языке Express-G показаны на рис. 3.
Для binary и STRING в круглых скобках можно указать максимально возможное число элементов множества, например, если строка A может включать до 24-х символов, то:
A: STRING(24);
Если строка должна содержать ровно 24 символа, то:
A: STRING(24) FIXED;
Если же ограничений на длину строки нет, то:
A: STRING;
Если переменная х имеет тип binary, то выражение х[5:7] означает биты с 5-го по 7-й в коде х.
Значения простых типов выражаются с помощью литералов. Литералы — это числа (целые, вещественные), двоичные коды, логические значения (true, false, unknown), фрагменты текста (строковый тип). Примеры записи литералов:
  • двоичный (начинается с знака %) %100101110
  • целое десятичное число 1052
  • вещественный (обязательна десятичная точка) 34.е-3 или 0.034
  • -троковый (занимает не более одной строки) 'first name'
Агрегативный тип данных — множество элементов некоторого типа.
Различают четыре разновидности агрегативных типов, сведения о которых приведены в табл. 1.
Таблица 1
Тип данных | Упорядоченность | Различие элементов
ARRAY | Да | Необязательно
BAG | Нет | Необязательно
LIST | Да | Обязательно
SET | Нет | Обязательно

При описании типа массив (array) после слова array в квадратных скобках указываются нижняя и верхняя границы индексов. Для остальных агрегативных типов записываются не граничные значения индекса, а нижняя и верхняя границы числа элементов. Например:
F1: ARRAY[2:8] of REAL;
(* массив F1 из 7-и элементов, элементы имеют тип REAL и нумеруются, начиная с индекса 2 *);
F2: LIST[1:?] of INTEGER;
(* множество F2 содержит, по крайней мере, один элемент типа INTEGER *)
matr: ARRAY[1:10] of ARRAY[9:12] of atrac;
(* массив matr состоит из 10 четырехэлементных массивов, элементы типа atrac *)
Записи вида array[2:8] или list[1:?] в Express-G преобразуются в форму A[2:8] или L[1:?], указываемую около линии атрибута агрегативного типа после имени этого атрибута. Так, первый из вышеприведенных примеров представлен на рис. 4.
Рис. 4. Пример изображения агрегативного типа в языке Express-G
Определяемый тип данных обычно вводится пользователем для улучшения читаемости модели. Нечисловой тип — тип данных, экземплярами которого являются нечисловые (предметные) переменные. Выделяемый тип соответствует поименованной совокупности других типов. Описание этих типов данных начинается со служебного слова type, за которым следует идентификатор типа и его определение. Пример описания определяемого типа:
TYPE volume = real;
END_TYPE;
ENTITY manual;
name: STRING;
v1,v2,v3: volume;
END_ENTITY;
Определение нечислового типа начинается со служебных слов enumeration of, после которых в скобках перечисляются элементы множества. Например:
TYPE color = ENUMERATION OF (red, green, blue);
END_TYPE;
Ссылка на значение red теперь возможна в виде red или color.red.
Выделяемый тип соответствует одному из некоторого списка уже введенных типов. Этот список записывается после служебного слова select. Ссылка на имя выделяемого типа означает, что выбирается один из типов совокупности:
TYPE a_c = SELECT (one, two, three);
END_TYPE;
...
proc: a_c; (* proc может быть объектом одного из типов one, two, three *)
Графические изображения определяемых, нечисловых и выделяемых типов данных показаны на рис. 5. Внутри прямоугольников, ограничиваемых пунктирными линиями, записывается имя типа.
Рис. 5. Изображения определяемых, нечисловых и выделяемых типов данных в языке Express-G
Способ описания констант очевиден из следующего фрагмента модели:
CONSTANT
year: INTEGER := 1995;
start: date := date(12,16,1982);
(* подразумевается, что при описании типа date указаны три атрибута
 месяц, число, год *)
END_CONSTANT;


Язык Express: Супертипы и подтипы
Отношения агрегирования (типа целое-часть) или отношения обобщения (функция-вариант реализации), характерные для представления структур объектов в виде альтернативных (И-ИЛИ) деревьев, в языке Express выражаются в форме отношений между типами данных. Для этого введены понятия супертипа (supertype), как более общего типа, и подтипов (subtypes), как подчиненных типов. На рис. 1 верхняя сущность относится к супертипу, а три нижних прямоугольника изображают подтипы, линии связи прямоугольников должны быть утолщенными.
Рассмотрим пример фрагмента И-ИЛИ-дерева, в котором имеется ИЛИ вершина a1 и две подчиненные ей альтернативные вершины b1 и b2. Общим атрибутом для b1 и b2 является size типа real, специфичный для b1 атрибут — vol типа real, а специфичный для b2 атрибут met типа string. Этот фрагмент может быть описан следующим образом:
ENTITY a1
SUPERTYPE OF (ONEOF (b1,b2));
size: REAL;
END_ENTITY;
ENTITY b1
SUBTYPE OF (a1);
vol: REAL;
END_ENTITY;
ENTITY b2
SUBTYPE OF (a1);
met: STRING;
END_ENTITY;
Используются также следующие правила записи супертипов и подтипов:
  • в случае, если a1 есть И вершина, вместо oneof используется зарезервированное слово and (в более общем случае andor), т.е. вторая строчка примера будет выглядеть так: supertype of (b1 and b2);
  • если между подтипами нет взаимосвязи, выражаемой логической функцией (в частности, ИЛИ или И вершинами), то указание в a1 факта, что это супертип, не требуется; достаточно упоминание о подчиненности подтипов в их декларациях в виде: subtype of (a1);
  • перед декларацией supertype записывается зарезервированное слово abstract, если вершине a1 не соответствуют какие-либо экземпляры сущности, т.е. если a1 введена только для указания общих для подтипов атрибутов;
  • у одного подтипа может быть больше одного супертипа; подтип наследует атрибуты всех своих супертипов; если в декларациях супертипов используются одинаковые идентификаторы атрибутов, то ссылка на них должна быть в виде составного идентификатора, например: a1.size.
Пример 1
ENTITY device
SUPERTYPE OF (ONEOF (transistor, diode));
(* device есть ИЛИ вершина И-ИЛИ-дерева с двумя альтернативами transistor и diode *)
END_ENTITY;
ENTITY transistor
SUBTYPE OF (device);
b: REAL;
END_ENTITY;
ENTITY diode
SUBTYPE OF (device);
r: REAL;
END_ENTITY;
Рис. 1. Изображение супертипов и подтипов в языке Express-G


Язык Express: ограничения
Ограничения, накладываемые на экземпляры сущности, выражаются с помощью правил (rules). Правила могут быть общими или локальными.
Описание правила, общего для ряда сущностей, начинается со служебного слова rule, далее следуют идентификатор правила, служебное слово for, ссылки на сущности, на которые правило распространяется, и, наконец, собственно ограничения.
Локальные правила могут описывать ключевые атрибуты (uniqueness rules) или выражать ограничения, накладываемые на атрибуты некоторой сущности (domain rules). Например, если ключевой атрибут сущности Z есть составной атрибут X.Y, или, другими словами, одному сочетанию значений атрибутов X и Y должен соответствовать единственный экземпляр сущности Z, то
ENTITY Z;
X: INTEGER;
Y: STRING;
UNIQUE
X,Y;
END_ENTITY;
Ограничение на атрибуты некоторой сущности выражается с помощью правила в теле этой сущности. Ограничение записывается после слова where в виде выражения, значениями которого могут быть true, false или unknown. Допустимыми значениями атрибута будут только те, для которых выражение принимает значение true. Например, можно записать, что длина вектора vect = (x,y,z) должна быть равна единице, в виде правила cons:
ENTITY vect;
x,y,z: REAL;
WHERE
cons: x**2 + y**2 + z**2 = 1.0;
END_ENTITY;
Ограничение where можно использовать в опредляемых типах, например:
TYPE size = REAL;
WHERE SELF < 12.0;
END_TYPE;
Здесь служебное слово SELF заменяет идентификатор определяемого типа, т.е. в данном примере значения size должны быть меньше 12.
Пример 1
ENTITY date;
day: INTEGER; month: months;
year: INTEGER;
WHERE
days_ok: {1 <= day <= 31};
year_ok: year>0;
date_ok: valid_date(SELF);
END_ENTITY;


Язык Express: процедуры и функции
Процедуры и функции в языке Express служат для описания процедурной части модели. Как и в алгоритмических языках, используется концепция формальных и фактических параметров. Описание процедуры начинается с служебного слова procedure, за которым следуют идентификатор процедуры и описание формальных параметров в круглых скобках. Пример описания заголовка процедуры:
PROCEDURE eq (x,y: REAL; n: INTEGER; VAR RESULT: route);
Аналогично описываются функции, их отличает только описание в заголовке типа результата после закрывающей скобки:
FUNCTION log (a: REAL; m: INTEGER): REAL;
Локальные переменные, описанные в блоке действуют только в пределах данных функции или процедуры:
LOCAL
...
END_LOCAL;
Ряд функций и процедур относится к стандартным и потому не требует описания во вновь разрабатываемых моделях. Отметим следующие стандартные функции: Abs — абсолютная величина; Sqrt — корень квадратный; Exp — экспонента; Log, Log2, Log10 — логарифмы натуральный, двоичный, десятичный соответственно; Sin, Cos, Tan, Acos, Asin, Atan — тригонометрические и обратные тригонометрические функции sin, cos, tg, arc cos, arc sin, arc tg.
В число стандартных входят также функции: BLength — подсчет числа бит в двоичном коде; HiBound — верхняя граница индекса у array или верхняя граница числа элементов у set, bag, list; LoBound — то же в отношении нижних границ; Length — подсчет числа символов в строке; Odd — возвращает значение true, если аргумент — нечетное число; SizeOf — возвращает число элементов в объекте агрегативного типа; TypeOf — возвращает список типов, к которым принадлежит параметр этой функции; Exists — возвращает значение true, если аргумент этой функции входит в число атрибутов соответствующей сущности, и др.
К стандартным процедурам относятся процедуры Insert и Remove — вставка или изъятие элемента в заданной позиции у объекта агрегативного типа соответственно.
При описании алгоритмов в телах процедур и функций могут использоваться операторы пустой (Null), присваивания (Assignment), выбора (Case), составной (Compound Statement), условный (if..then..else), цикла (Repeat), выхода из функции или процедуры (Return), перехода на конец цикла (Skip).
В выражениях используются операнды, знаки операций, вызовы функций. Так, для арифметических операций над числами типа real применяются следующие знаки: * — умножение, / — деление, DIV — целочисленное деление, + — сложение, - — вычитание, ** — возведение в степень, MOD — деление по модулю.
Знаки логических операций: not — отрицание, and — конъюнкция, or — дизъюнкция, xor — исключающее ИЛИ. В применении к величинам типа logical эти операции выполняются по правилам действий в трехзначном алфавите. Логическое выражение a1 in a2 принимает значение true, если a1 содержится в a2. Оператор like используется для посимвольного сравнения строк. Знаки отношений равно =, не равно <>, больше >, меньше <, больше или равно >=, меньше или равно <=. Для сравнения экземпляров сущностей используют операции "равно" и "неравно" со знаками :=: и :<>: соответственно.
Операции над множествами (типами bag и set) — пересечение (Intersection), объединение (Union), разность (Difference). Их знаки суть * (умножение), + (плюс), — (минус) соответственно. Оператор Query (A <* B | C) возвращает подмножество тех элементов из агрегативного типа B, для которых выполняется условие C, здесь A — простая переменная, используемая в C.
Знак + (плюс) по отношению к операндам типа binary или string есть знак конкатенации.
В качестве формальных параметров процедур и функций, кроме типов данных, применяемых в других конструкциях языка и охарактеризованных выше, могут использоваться обобщенные типы: generic, aggregate и некоторые другие. Тип generic формального параметра означает, что соответствующий фактический параметр может иметь любой тип данных из числа предусмотренных при описании процедуры. Аналогично тип aggregate обобщает агрегативные типы данных — array, bag, list, set. Например:
Пример 1
FUNCTION add (a,b: GENERIC: intype): GENERIC: intype;
LOCAL
nr: number;
vr: vector;
END_LOCAL;
IF ('number' IN TYPEOF (a)) AND ('number' IN TYPEOF (b))
THEN nr := a+b;
(* функция typeof (a) возвращает тип аргумента а и,
   если этот тип есть number, то первый операнд логического выражения равен true *)
RETURN (nr);
ELSE
IF ('this schema.vector' IN TYPEOF (a)) AND ('this schema.vector' IN TYPEOF (b)) THEN
vr.i := a.i + b.i;
vr.j := a.j + b.j;
vr.k := a.k + b.k;
(* подразумевается, что декларация типа vector
   была произведена в схеме с именем this schema *)
RETURN (vr);
END_IF;
END_IF;
END_FUNCTION;
В языке Express-G специальные символы для изображения правил, процедур и функций не оговорены.


Примеры моделей на языке Express
Пример 1
Пример модели "person_organization_schema", взятый из 41-го тома "Интегрированные ресурсы" стандарта STEP (ISO 10303.41), на языке Express:
SCHEMA person_organization_schema;
ENTITY address;
internal_location : optional label;
street_number : optional label;
street : optional label;
postal_box : optional label;
town : optional label;
region : optional label;
postal_code : optional label;
country : optional label;
facsimile_number : optional label;
telephone_number : optional label;
electronic_mail+address : optional label;
telex_number : optional label;
WHERE
wr1 : EXISTS(internal_location) OR EXISTS(street_number) OR EXISTS(street)
OR EXISTS(postal_box) OR EXISTS(town) OR EXISTS(region)
 OR EXISTS(postal_code)
OR EXISTS(country) OR EXISTS(facsimile_number) OR EXISTS(telephone_number)
OR EXISTS(electronic_mail_address) OR EXISTS(telex_number);
END_ENTITY;
ENTITY personal_address
SUBTYPE OF (address);
people : SET[1:?] OF person;
description : text;
END_ENTITY;
ENTITY person;
id : identifier;
last_name : OPTIONAL label;
first_name : OPTIONAL label;
middle_names : OPTIONAL LIST[1:?] OF label;
prefix_titles : OPTIONAL LIST[1:?] OF label;
suffix_titles : OPTIONAL LIST[1:?] OF label;
UNIQUE
ur1 : id;
WHERE
wr1 : exists(last_name) OR exists(first_name);
END_ENTITY;
END_SCHEMA;
Пример 2
Пример использования языка Express-G для представления модели "Определение изделия" из стандарта ISO 10303-41 показан на рис. 1.
Рис. 1. Пример модели "Определение изделия" на языке Express-G


Расширения языка Express
Расширение возможностей языка Express достигается путем введения его разновидностей. Так, в языке Express-C добавляются возможности описания событий и транзакций:
EVENT a;
WHEN b => c; (* здесь b - логическое выражение, с - обращение к
транзакции при b = true *)
END_EVENT;
TRANSACTION c;
LOCAL d: e;
END_LOCAL;
...
END_TRANSACTION;
При описании соответствия между двумя Express-моделями используются языки Express-X или Express-M. Например, в Express-M соответствие между схемой-источником A, в которой заданы атрибуты a1, a2, a3, и схемой-целью B, в которой те же атрибуты описаны идентификаторами b1, b2, b3, выражается следующим описанием:
SCHEMA map B A;
b1 := a1;
b2 := a2;
b3 := a3;
END_SCHEMA map;
При отображении возможны преобразования атрибутов, например, если [image] 1 задан в метрах, а [image] 1 в сантиметрах, то в примере нужно записать [image] 1 := [image] 1*100.
Для обмена конкретными значениями атрибутов между системами используются обменные файлы, структура которых задана стандартом ISO 10303, том 21.


Историческая справка
Первые программы автоматизированного проектирования были созданы для нужд электронной и радиотехнической промышленности. Они появились в конце 50-х - начале 60-х годов прошлого века. В качестве примера можно назвать программы анализа электронных схем Net-1, ECAP или программу логического моделирования цифровой аппаратуры С.Крея – Р.Киша, созданные в США. В СССР в 60-е годы появляются программы проектирования печатных плат, оформления конструкторской документации, логического и схемотехнического моделирования радиоэлектронной аппаратуры (РЭА) и интегральных схем.
Развитие систем автоматизированного проектирования в машиностроении тесно связано с аппаратно-программными средствами машинной графики и геометрического моделирования, так как проектирование механических изделий заключается прежде всего в конструировании, т.е. в определении геометрических форм тел и их взаимного расположения. Поэтому отправной точкой истории автоматизации проектирования в машиностроении обычно считают создание графической станции Sketchpad на основе дисплея и светового пера И.Сазерлендом в 1963 г., хотя еще в 1946 г. И.Шоенбергом была представлена теория B-сплайнов. В 70-е годы в геометрическом моделировании стали использовать неравномерные рациональные B-сплайны (NURBS), а также модели кривых и поверхностей любой формы, разработанные П.Безье. К 1982 г. твердотельное моделирование начинают применять в своих программных продуктах компании Computervision, IBM, Prime и др. В 1986 г. компания Autodesk выпускает свой первый CAD-продукт Autocad. В 1988 г. создается аппаратура для прототипирования изделий с помощью лазерной стереолитографии по данным, получаемым в САПР. Также в 1988 г. компания PTC впервые реализует параметризацию моделей.
Развитие компьютерной графики определялось не только возможностями аппаратных средств, но и характеристиками программного обеспечения. Оно должно было быть инвариантным по отношению к используемым аппаратным средствам ввода и вывода графической информации. Поэтому значительное внимание с 70-х годов уделяется вопросам стандартизации графических программ. Стандарт на базисную графическую систему включает в себя функциональное описание и спецификации графических функций для различных языков программирования.
В 1977 г. ACM публикует документ Core, описывающий требования к аппаратно-независимым программным средствам. А в начале 1982 г. появляется система Graphical Kernel System (GKS), задающая примитивы, сегменты и преобразования графических данных и ставшая стандартом ISO в 1985 г. В 1987 г. разработан вариант GKS-3D с ориентацией на 3D графику.
В 1986 г. утверждается ряд новых стандартов в области компьютерной графики. Среди них CGI (Computer Graphics Interface) и PHIGS P (Programmer's Hierarchical Interactive Graphics System) - стандарт ANSI, ставший стандартом ISO в 1989 г. В 1993 году компанией Silicon Graphics предложен стандарт OpenGL (SGI Graphical Language), широко используемый в настоящее время.
В этих системах используются графические форматы для обмена данными, представляющие собой описание изображения в функциях виртуального графического устройства (в терминах примитивов и атрибутов). Графический формат (метафайл) обеспечивает возможность запоминать графическую информацию единым образом, передавать ее между различными системами и интерпретировать для вывода на различные устройства. Такими форматами стали CGM - Computer Graphics Metafile, PostScript - Adobe Systems' Language, GEM - GEM Draw File Format и др.
Работы по стандартизации были направлены на расширение функциональности графических языков и систем, включение в них средств описания не только данных чертежей и 3D-моделей, но и других свойств и характеристик изделий.
В области автоматизации проектирования унификация основных операций геометрического моделирования привела к созданию инвариантных геометрических ядер, предназначенных для применения в разных САПР. Наибольшее распространение получили два геометрических ядра Parasolid (продукт фирмы Unigraphics Solutions) и ACIS (компания Spatial Technology). Ядро Parasolid разработано в 1988 г. и в следующем году становится ядром твердотельного моделирования для CAD/CAM Unigraphics, а с 1996 г. – промышленным стандартом.
Параллельно проводились работы по стандартизации описаний геометрических моделей для обмена данными между различными системами на различных этапах жизненного цикла промышленной продукции. В 1980 г. появился формат IGES (Initial Graphics Exchange Specification), ставший на следующий год стандартом ANSI. Фирма Autodesk в своих продуктах стала использовать формат DXF (Autocad Data eXchange Format).
В 1984 г. в ISO для целей стандартизации в области промышленной автоматизации создается технический комитет TC184, а внутри него для разработки стандартов обмена данными - подкомитет SC4, где и была разработана группа стандартов ISO 10303 STEP (Standard for Exchange Product Model Data), включая язык Express и прикладные протоколы AP203 и AP214.
Примерами CAD/CAM-систем верхнего уровня являются CATIA (компания Dassault Systemes), Unigraphics (Unigraphics Solution), Pro/Engineer (PTC). Продукты этих фирм доступны с 1981, 1983 и 1987 г. соответственно. К числу САПР верхнего уровня в 90-е годы относились также EUCLID3 (Matra Datavision), I-DEAS (SDRC), CADDS5 (Computervision), но их развитие было прекращено в связи со слиянием компаний.
Так, в 2001 г. происходит слияние компании Unigraphics Solution с SDRC, что означало постепенное прекращение развития I-DEAS и использование удачных решений двух систем I-DEAS и Unigraphics (UG) в новых версиях системы Unigraphics NX. Еще раньше система CADDS5 была приобретена компанией PTC (Parametric Technology Corp.).
В 1992 году корпорация Intergraph, один из ведущих на тот момент производителей CAD-систем для машиностроения, приняла решение о разработке нового программного продукта, целиком построенного на базе платформы Wintel. В результате в конце 1995 года появилась система среднего уровня для геометрического моделирования Solid Edge. В 1998 году к Unigraphics перешло все отделение Intergraph, занимающееся САПР для машиностроения. В это же время Solid Edge меняет геометрическое ядро ACIS на ядро Parasolid.
В 1993 г. в США создается компания Solidworks Corporation и уже через два года она представила свой первый пакет твёрдотельного параметрического моделирования Solidworks на базе геометрического ядра Parasolid. Система Solidworks вошла в число ведущих систем среднего уровня.
Ряд CAD/CAM систем среднего и нижнего уровней разработан в СССР и России. Наибольшее распространение среди них получили Компас (компания Аскон), Кредо (НИЦ АСК), T-Flex CAD (Топ Системы) и некоторые другие системы.
Компания Аскон основана в 1989 г. В нее вошел коллектив разработчиков, который до этого в Коломенском конструкторском бюро машиностроения проектировал систему Каскад. Первая версия Компас для 2D проектирования на персональных компьютерах появилась в том же 1989 г. В 2000 г. САПР Компас распространена на 3D проектирование. В 2003 г. выпущена 6-я версия Компас и PDM система Лоцман.PLM.
Автоматизация технологической подготовки производства в системах CAM не была столь жестко привязана к аппаратным средствам машинной графики, как автоматизация конструирования в системах CAD. Среди первых работ по автоматизации проектирования технологических процессов нужно отметить создание языка APT (Automatic Programming Tools) в 1961 г. в США. Этот язык стал родоначальником многих других языков программирования для оборудования с числовым программным управлением. В СССР Г.К.Горанский создает программы для расчетов режимов резания в первой половине 60-х годов. В.Д.Цветков, Н.М.Капустин, С.П.Митрофанов и др. разрабатывают методы синтеза технологических процессов в 70-е годы.
В системах инженерных расчетов и анализа CAE центральное место занимают программы моделирования полей физических величин, прежде всего это программы анализа прочности по методу конечных элементов (МКЭ).
Метод конечных элементов разработан к 1950 г. специалистами, работающими в областях строительной механики и теории упругости. Сам термин "конечные элементы" был введен в 1960 г. Клафом (R.Clough). В 1963 г. был предложен сравнительно простой способ применения МКЭ для анализа прочности путем минимизации потенциальной энергии. Появились программно-методические комплексы для анализа и моделирования на основе МКЭ.
В 1965 г. NASA для поддержки проектов, связанных с космическими исследованиями, ставит задачу разработки конечно-элементного программного пакета. К 1970 г. такой пакет под названием NASTRAN (NAsa STRuctural ANalysis) был создан и начал эксплуатироваться. Стоимость разработки, продолжавшейся 5 лет, составила 3-4 млн долларов. Одной из компаний, участвовавших в разработке, была MSC (MacNeal-Schwendler Corporation). С 1973 г. MSC (с 1999 г. компания называется MSC.Software Corporation) самостоятельно продолжает развивать пакет MSC.NASTRAN, который стал мировым лидером в своем классе продуктов, и ряд других программ, объединяемых в общую среду виртуальной разработки изделий.
В 1976 г. разработан комплекс DYNA3D (позднее названный LS-DYNA), предназначенный для анализа ударно-контактных взаимодействий деформируемых структур.
К числу лидеров программ CAE можно отнести также комплекс Ansys. В 2000 г. с помощью средств многоаспектного моделирования, реализованных в Ansys, продемонстрирована возможность совместного моделирования электромагнитных, механических и тепловых процессов при проектировании микроэлектромеханических устройств.
Мировым лидером среди программ анализа на макроуровне считается комплекс Adams, разработанный компанией Mechanical Dynamics Inc. (MDI), созданнной в 1977 г. В настоящее время развитием комплекса занимается MSC.Software Corporation. Основное назначение Adams (Automatic Dynamic Analysis of Mechanical Systems) - кинематический и динамический анализ механических систем с автоматическим формированием и решением уравнений движения.
Для проектирования систем, функционирование которых основано на взаимовлиянии процессов различной физической природы, важное значение имеет возможность многоаспектного моделирования. Теоретические основы многоаспектного моделирования на базе аналогий физических величин рассматривались Г.Ольсоном (1947 г.), В.П.Сигорским (1975 г.) и были реализованы в программах моделирования ПА6 - ПА9, разработанных в МВТУ им. Н.Э.Баумана в 70-80-е годы. Основные положения многоаспектного моделирования позднее были закреплены в стандарте, посвященном языку VHDL-AMS.
В области автоматизации управления прежде всего нужно отметить так и нереализованные работы по созданию ОГАС - общегосударственной автоматизированной системы управления экономикой, выполненные еще в 1964 г. под руководством В.М.Глушкова. В настоящее время существует и применяется ряд автоматизированных систем управления. Мировым лидером в области ERP-систем на протяжении многих лет является система R/3 компании SAP. Эту компанию образовали пятеро ушедших из IBM системных аналитиков в 1972 г. Их первая многофункциональная система управления предприятием R/2, работающая на мейнфреймах, появилась на свет в 1978 г., а современная система R/3 - в 1989 г.
Необходимость создания и использования CALS (ИПИ)-технологий была понята в процессе роста сложности проектируемых технических объектов. Работы по CALS были инициированы в оборонной промышленности США. Более конкретно возникновение CALS многие относят к периоду попыток США выполнить программу «звездных войн» - СОИ (стратегической оборонной инициативы) в середине 80-х годов.
С тех пор работы по CALS ведутся в направлениях: стандартизации языков и форматов представления, хранения и обмена данными; интегрированной логистической поддержки изделий; создания систем управления данными на всех этапах жизненного цикла изделий; развития интерактивных электронных технических руководств.
Международная организация стандартизации принимает в 1986 г. стандарт на язык разметки SGML; в 1988 г. – стандарт EDIFACT; в 1991 г. разработан проект языка Express и в 1994 г. утверждены первые стандарты STEP, задающие язык Express и методы его реализации для описания моделей изделий в разных приложениях. При создании этих стандартов были учтены более ранние разработки по функциональному и информационному моделированию процессов и приложений. Это прежде всего методика SADT, разработанная Д.Россом в 1973 г. и послужившая основой для спецификации IDEF0 в рамках выполнявшейся в США программы ICAM (Integrated Computer Aided Manufacturing). В 1999 г. первые стандарты STEP, переведенные на русский язык, становятся также стандартами России.
Большой объем данных, используемых при проектировании, необходимость поддержания их целостности (достоверности и полноты), сложность управления проектированием привели в 80-е годы к созданию в составе САПР системных сред, называемых системами управления проектными данными PDM (Product Data Management).
Появление системных сред в САПР ознаменовало переход от использования отдельных не связанных друг с другом программ, решающих частные проектные задачи, к применению интегрированной совокупности таких программ. Роль интегрирующего компонента в 70-е гг. возлагалась на единую базу данных САПР. Однако попытки использовать имевшиеся в то время СУБД не приводили к удовлетворительным результатам в силу разнообразия типов проектных данных, распределенного и параллельного характера процессов проектирования, с одной стороны, и недостаточной развитости технологии баз данных, с другой стороны.
Первой PDM-системой в начале 80-х годов стал продукт EDL компании CDC. В САПР электронной промышленности первые системы управления проектированием и проектными данными, называвшиеся системными средами (Framework), созданы в середине 80-х годов. Это системы Skill и Falcon Frameworks фирм Cadence Design Systems и Mentor Graphics соответственно.
Начиная с середины 90-х годов, разворачиваются работы по PDM для САПР в машиностроении.
Одной из первых развитых PDM-систем становится система Optegra компании Computervision. Unigraphics Solutions (UGS) совместно с Kodak разрабатывает PDM-систему iMAN. С покупкой в январе 1998 года компании Computervision и её PDM-технологии Windchill фирма PTC вышла на рынок PDM-систем. Cистема Windchill является первой Internet-ориентированной PDM-системой. В 1999 году фирма РТС анонсирует новую технологию СРС - Collaborative Product Commerce, базирующуюся на технологии Windchill. В начале XXI века появляются PDM-системы ENOVIA и Smarteam от Dassault Systemes, Teamcenter от UGS и ряд других.
Среди российских систем PDM наиболее известными являются Party Plus (компания Лоция-Софт), PDM STEP Suite, разработанная под руководством Е.В.Судова в НПО «Прикладная логистика» в 2002 г., Лоцман:PLM в составе САПР Компас компании Аскон.
Расширение функций PDM-систем на все этапы жизненного цикла продукции превращает их в системы PLM (Product Lifecycle Management).


Изучение языка Express на основе программного комплекса EDM
Среди программных систем, поддерживающих STEP-технологию, наиболее известны продукты компаний STEP Tools и EPM Technology. Ниже изложены некоторые приемы работы с программами комплекса EDM (Express Data Manager) компании EPM Technology. Эти приемы нужно освоить для выполнения лабораторной работы, посвященной освоению STEP -технологии и языка Express.
В процессе выполнения лабораторной работы рекомендуется изучить и освоить:
  • средства языка Express-G и приемы описания прикладной задачи на языке Express-G;
  • формирование обменного файла в соответствии с протоколом ISO 10303-21.
В первой части работы следует ознакомиться с приводимым далее кратким руководством по использованию программного комплекса EDM, выполнив операции моделирования для рассмотренных в руководстве примеров. Во второй части нужно создать Express-схему и обменный файл для задачи, предложенной преподавателем.
Создание схемы с помощью EDMvisualExpress.
Лабораторную работу следует начать с создания базы данных или открытия уже существующей БД.
После открытия БД нужно задать новую диаграмму с помощью выбора иконки New diagram (рис. 1), присвоив диаграмме имя, например, diag. Далее рассматривается простой пример создания схемы и обменного файла для модели, описывающей отрезок прямой линии.
Сначала используя иконки Create Entity и Text Edit, следует создать два изображения сущностей line и point, затем с помощью Create Real — изображение простого типа Real. Изображения атрибутов создаются с помощью иконки Create Attribute — нужно выбрать родительскую сущность, затем кнопку Create Attribute, затем дочернюю сущность. Появляются линии атрибутов с надписями вида "Attribute_1". Двойной клик на этой надписи приводит к появлению окна, в котором можно задать имя атрибута и в случае агрегативного типа — его размерность. Модель с выбранными именами сущностей и атрибутов принимает вид рис. 2.
Рис. 1.
Одновременно с появлением изображений в окне вывода в левой части окна можно увидеть иерархию создаваемых сущностей и атрибутов. Выбор иконки Validate позволяет увидеть схему на языке Express (рис. 3), соответствующую модели рис. 2.
Рис. 2.
Рис. 3.
Сохранить созданную схему можно, выбрав иконку Write EXPRESS source (см. рис. 1). Для получения HTML-файла нужно перейти из EDMvisualExpress в EDMSupervisor и в режиме Schemata > Make HTML format указать выбранное имя HTML-файла.
Использование внешней схемы
В комплексе EDM можно работать как со схемами, созданными в EDMvisualExpress, так и импортируемыми извне. Текстовый файл внешней схемы должен иметь расширение exp.
Работа с файлом происходит после его определения в среде программы EDMSupervisor в режиме Schemata > Define Schema. При этом в указанном пользователем диагностическом файле появляются диагностические сообщения.
Создание экземпляров сущностей и обменного файла с помощью EDMSupervisor
После входа в EDMSupervisor и открытия БД требуется создать репозиторий и модель в режиме Data > Create>Repository и Data > Create>Model.
Экземпляры модели создаются в режиме Data >Create > Instance. В случае схемы diag можно начать с создания экземпляра сущности line. В появляющемся окне рис. 4 нужно выбрать позицию >, и в следующем окне атрибут P0 сущности line связывается с сущностью point с помощью выбора иконки Connect и затем иконки Next. Появляется окно рис. 5, в котором снова нужно указать >, что вызывает окно рис. 6. В этом окне в строке Value последовательно указываются значения трех координат точки P0 (после записи очередного значения нужно нажать кнопку Update). Затем с помощью Prev дважды осуществляем возврат в предыдущие окна, чтобы повторить такие же операции для точки P1. После этого можно выходить из режима создания модели.
Рис. 4.
Рис. 5.
Рис. 6.
Обменный файл (иначе, STEP файл) служит для экспорта созданной модели. Для создания обменного файла (в соответствии с ISO 10303-21) нужно войти в режим Data > Export Model и в появившемся окне рис. 7 указать выбранный адрес обменного файла (с расширением stp), например, как показано на рис. 7. Увидеть содержимое созданного файла можно в режиме Data > Show>STEP file. Для схемы diag обменный файл может иметь следующий вид (в примере P0=(2, 34, 5), P1=(0, 0, 10)):
ISO-10303-21;
HEADER;
FILE_DESCRIPTION((),'2;1');
FILE_NAME('mod3','2006-02-19T08:04:50',('ANONYMOUS USER'),('ANONYMOUS ORGANISATION'),
   'EXPRESS Data Manager version 20050406',$,$);
FILE_SCHEMA(('DIAG'));
ENDSEC;

DATA;
#1= LINE(#2,#4);
#2= POINT((2.,34.,5.));
#4= POINT((0.,0.,10.));
ENDSEC;

END-ISO-10303-21;
Рис. 7.
Обменный файл в виде XML-документа в соответствии с протоколом ISO 10303-28 можно получить в режиме Data > XML >Write XML document, задав определенное имя XML-файла. В нашем примере файл имеет вид:
<?xml version="1.0" encoding="UTF-8"?>
<ex:iso_10303_28 xmlns:
xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:ex="urn:iso10303-28:ex"
xsi:schemaLocation="urn:iso10303-28:ex./ex.xsd" version="2.0">
<ex:uos id="uos_1" description="" configuration="default" edo="">

<line id="i160">
<p0>
<point xsi:nil="true" ref="i161"/>
</p0>
<p1>
<point xsi:nil="true" ref="i163"/>
</p1>
</line>
<point id="i161">
<X ex:cType="array" ex:arraySize="3">
<ex:double-wrapper>2.</ex:double-wrapper>
<ex:double-wrapper>34.</ex:double-wrapper>
<ex:double-wrapper>5.</ex:double-wrapper>
</X>
</point>
<point id="i163">
<X ex:cType="array" ex:arraySize="3">
<ex:double-wrapper>0.</ex:double-wrapper>
<ex:double-wrapper>0.</ex:double-wrapper>
<ex:double-wrapper>10.</ex:double-wrapper>
</X>
</point>
</ex:uos>
</ex:iso_10303_28>
Еще один пример
Рассмотрим получение STEP файла в системе EDM для следующей Express-схемы:
SCHEMA DIAG1;
  ENTITY docum;
      image : picture;
  END_ENTITY;
  ENTITY picture SUPERTYPE OF (ONEOF(circle ANDOR line));
      annot : STRING;
  END_ENTITY;
  ENTITY circle
    SUBTYPE OF(picture);
      radius : REAL;
      center : point;
  END_ENTITY;
  ENTITY line
    SUBTYPE OF(picture);
      p0 : point;
      p1 : point;
  END_ENTITY;
  ENTITY point;
      x : ARRAY [1:2] OF REAL;
  END_ENTITY;
END_SCHEMA;
После создания репозитория и модели вводятся экземпляры сущностей. В нашем примере сначала описываются три экземпляра сущности point (выбраны координаты точек (0;0), (1;1) и (12;4,5). Далее создается экземпляр сущности circle в режиме Create > Instance. Появляются окна Create Instance и далее Instance и Select (рис. 8). В окне Instance набираются значения Line и 7.5 (после каждого набора нажимается кнопка Update), затем выбирается кнопка > и в окне Select выбирается ConnectExistingInstance, так как экземпляры точек уже введены (иначе нужно было бы выбрать ConnectNewInstance). В окне рис. 9 выбирается сущность point и в строке First instance index to check указывается нужный номер экземпляра point (в нашем случае это 0). В появляюшемся окне нужно нажать кнопку Connect.
Рис. 8.
Рис. 9.
Аналогичным образом создаются экземпляры сущностей line и docum. Полученный STEP файл имеет вид:
ISO-10303-21;
HEADER;
  FILE_DESCRIPTION((),'2;1');
  FILE_NAME('mod','2006-02-24T16:04:35',('ANONYMOUS USER'),('ANONYMOUS ORGANISATION'),
     'EXPRESS Data Manager version 20050406',$,$);
  FILE_SCHEMA(('DIAG1'));
ENDSEC;
 DATA;
   #1= POINT((0.,0.));
   #3= POINT((1.,1.));
   #5= POINT((12.,4.5));
   #7= LINE('Line',#3,#5);
   #8= CIRCLE('Circle',7.5,#1);
   #9= DOCUM(#8);
   #10= DOCUM(#7);
 ENDSEC;
END-ISO-10303-21;


Использование языка VHDL для моделирования цифровых устройств на регистровом уровне
Цель работы: освоение языка VHDL для использования в задачах описания и анализа дискретных устройств (на регистровом уровне).
Техническое задание: Описать на языке VHDL счетчик по модулю 10 на синхронных двухступенчатых JK-триггерах с запрещающими связями и промоделировать его работу.
Практическая часть
Пусть необходимо дать описание на языке VHDL счетчика по модулю 10, построенного на JK-триггерах с запрещающими связями (см рис. 1 и рис. 2). Полученное описание должно быть использовано для анализа поведения устройства средствами системы моделирования и анализа Active-VHDL.
Рис. 1. Логическая схема счетчика
Рис. 2. Логическая схема JK-триггера
Используемые для построения счетчика элементы могут быть представлены в языке VHDL двояко:
  • функционально — путем задания выполняемых логических функций (с учетом задержек сигналов).
  • структруно — путем задания их логической схемы.
Например, функциональное описание элемента 2И выглядит следующим образом:
entity and2 is
 port (
    x1: in BIT;
    x2: in BIT;
    o: out BIT );
end and2;
architecture and2 of and2 is
 begin
     o<= x1 and x2 after delay; -- delay - задержка на элементе
 end and2;
Структурное описание JK-триггера в базисе элементов 3И-НЕ выглядит следующим образом:
entity jktrigger is
 port (
     R: in BIT;
     S: in BIT;
     J: in BIT;
     C: in BIT;
     K: in BIT;
     Q: out BIT;
     NQ: out BIT
      );
end jktrigger;

architecture jktrigger of jktrigger is
   component and_no_3
          port (
             x1: in BIT;
             x2: in BIT;
             x3: in BIT;
             o: out BIT
              );
    end component;
    signal Q1,Q2,Q3,Q4,Q5,Q6,Q7,Q8: BIT;
    begin
          E1: and_no_3
                port map (Q8, J, C, Q1);
          E2: and_no_3
                port map (Q7, K, C, Q2);
          E3: and_no_3
                port map (S, Q1, Q4, Q3);
          E4: and_no_3
                port map (Q3, Q2, R, Q4);
          E5: and_no_3
                 port map (Q2, Q3, Q1, Q5);
          E6: and_no_3
                 port map (Q2, Q4, Q1, Q6);
          E7: and_no_3
                 port map (S, Q5, Q8, Q7);
          E8: and_no_3
                 port map (Q7, Q6, R, Q8);
          Q <= Q7;
         NQ <= Q8;
 end jktrigger;
Рассматриваемый в примере счетчик на основе JK-триггеров и элементов 2И описывается так:
entity counter is
   port (
            reset: in BIT;
            clk: in BIT;
            q: out BIT_VECTOR (4 downto 1)
            );
  end counter;

architecture counter of counter is
 component jktrigger
        port (
                  R: in BIT;
                  S: in BIT;
                  J: in BIT;
                 C: in BIT;
                 K: in BIT;
                 Q: out BIT;
                 NQ: out BIT
               );
        end component;
  component and2
         port (
                  x1: in BIT;
                  x2: in BIT;
                  o: out BIT
                 );
 end component;
 signal Q1, NQ1, Q2, NQ2, Q3, NQ3, Q4,NQ4,L1,L2,L3: BIT;
 begin
     T1: jktrigger
            port map (Reset, '1','1',CLK,'1',Q1, NQ1);
     T2: jktrigger
            port map (Reset, '1', L1, CLK, Q1, Q2,NQ2);
     T3: jktrigger
            port map (Reset, '1', L2, CLK, L2, Q3,NQ3);
     T4: jktrigger
            port map (Reset, '1', L3, CLK, Q1, Q4, NQ4);
     A1: and2
            port map (Q1, NQ4, L1);
     A2: and2
            port map (Q1, Q2, L2);
     A3: and2
            port map (Q3, L2, L3 );
     q(1) <=  Q1;
     q(2) <=  Q2;
     q(3) <=  Q3;
     q(4) <=  Q4;
end counter;
Работа с программой Active-VHDL
1. Для того, чтобы создать новый проект, запустите Active-VHDL или, если система уже запущена, воспользуйтесь пунктом New Design меню File. С помощью New Design Wizard вы создадите необходимые для вашего проекта файлы, библиотеки и шаблоны элементов (см. рис. 3):
Рис. 3.
Примечание 1
  • файлы, содержащие описание на языке VHDL, имеют, как правило, расширение .vhd.
  • библиотеки содержат необходимые для компиляции и моделирования данные о проекте.
  • шаблоны, генерируемые системой на данном этапе, представляют собой описание интерфейса структурного элемента, подготовленное для внесение в него описания архитектуры элемента, создаваемого пользователем.
В первом в порядке появления окне New Design Wizard задайте название вашего проекта, его месторасположение в файловой системе операционной системы и название сопутствующей ему библиотеки (по умолчанию используется то же имя, что и для всего проекта).
Во втором окне New Design Wizard существует возможность выбора следующих действий:
  • Create new source files now — создание описаний структурных элементов проекта на языке VHDL с помощью New Design Wizard.
  • Add existing resource files — добавление к новому проекту уже существующих файлов.
  • Import a design from Active-CAD — использование проектов, созданных в системе Active CAD.
  • Create an empty design — создание проекта с пустыми файлами. Этот пункт используется в том случае, если вы не хотите использовать возможности New Design Wizard для создания шаблонов.
Для облегчения работы и ознакомления с возможностями системы выберите пункт Create new source files now.
В следующем окне New Design Wizard вам будет необходимо описать элементы, присутствующие в проекте. Для добавления элемента нажмите кнопку New, в поле Entity name введите имя элемента, в поле Source Type — тип описания элемента (в нашем случае для всех элемнтов необходимо выбрать тип VHDL Code). Для каждого вновь создаваемого элемента необходимо задать входы и выходы (в дальнейшем порты) с помощью окна Design Wizard — Ports, которое вызывается кнопкой Ports. Для каждого порта (создание нового порта начинается с нажатия кнопки New) надо указать его имя, направление и тип: вход — in, выход — out, шина — buffer (размерность шины выбирается в поле Array Indexes, где указывается максимальный и минимальынй номера портов в шине). Тип порта устанавливается нажатием кнопки Types, где для обычного порта выбираем тип BIT, а для шины — BIT_VECTOR. На данном этапе необходимо создать следующие элементы:
  • 3И-НЕ, из которых будет создаваться JK-триггер. Элемент имеет три входа и один выход.
  • Сам триггер, имеющий следующие порты: входные R, S, J, C, K и выходные Q и NQ.
  • 2И, необходимые для построение счетчика. Элемент имеет два входа и один выход.
  • Счетчик со следующими портами: входные Reset и CLK, выходная шина q(4,1)
В следующем окне New Design Wizard проверьте информацию о вашем проекте и, в случае ее правильности, нажмите кнопку Finished. Если вы хотите изменить какую-либо информацию, вернитесь на предыдущие этапы с помощью кнопки Back.
2.Итак, исходные файлы для вашего проекта созданы. Файловую структуру проекта вы можете увидеть в окне Design Browser (его можно включить, выбрав соответствующий пункт в меню View), выбрав закладку Files. Если предыдущие этапы были пройдены успешно, окно Design Browser должно выглядеть примерно так, как показано на рис. 4. Здесь присутствуют: пункт Add New File, которым можно воспользоваться в случае необходимости добавить еще какие-либо элементы к вашему проекту (например, если вы забыли создать какой-то элемент на предыдущих этапах), файл библиотеки test library, и четыре файла с VHDL-кодом ваших элементов, созданным New Design Wizard. Цвета иконок в окне имеют слудующий смысл:
  • синий — файлы еще не были откомпилированны или были изменены после послденей компиляции;
  • зеленый — файл был откомпилирован успешно;
  • красно-желтый — обнаружение ошибки в компилировавшемся файле.
Рис. 4.
Следить за ходом работы над проектом, обнаруженными ошибками и другой информацией вы можете в окне Console (включается через меню View).
3.Для того, чтобы посмотреть VHDL-код, созданный посредством New Design Wizard, изменить или дополнить его, необходимо выбрать желаемый файл, нажать правую кнопку мыши и в появившемся меню выбрать пункт Open. Во вновь открывшемся окне вы увидите описание элемента, сгенерированное New Design Wizard. Как видно из рис. 5, описаны только порты элемента, его же поведение (функциональность) необходимо описать самостоятельно, т.е. вставить необходимый код вместо надписи -- <<enter your statements here>>. Элементы самого нижнего уровня (3И-НЕ и 2И) необходимо описать функционально. Например, для элемента 3И-НЕ вставляемый текст может выглядеть следующим образом: o <= not (x1 and x2 and x3) after delay;
Рис. 5.
Откомпилируйте готовый код элемента (кнопка Compile на панели инструментов или пункт Compile в контекстном меню). Если в коде есть ошибки (иконка файла стала желто-красной), найдите их с помощью окна Console, исправьте и откомпилируйте заново, пока иконка файла не станет зеленым.
4.Для того, чтобы проверить правильность работы элемента, промоделируем его и построим временные диаграммы. Для этого выберем рассматриваемый элемент как верхний уровень в верхней части Design Browser (Top-Level selection) и перейдем на закладку Structure окна Design Browser. Здесь вы увидите структуру элемента, например, какие элементы нижнего уровня он включает. Пока рассматриваемый элемент сам является элементом низшего уровня. В нижней части окна Design Browser теперь находится информацию о портах элемента и значениях сигналов на портах. Так как моделирование еще не проводилось, значения не определены.
Для создания новой временной диаграммы нажмите кнопку Create New Waveform. Откроется новое окно. Перетащите из нижней части Design Browser в поле Name нового окна имена тех сигналов, для которых вы хотите построить временные диаграммы. Для того, чтобы задать входные сигналы, необходимо нажать кнопку Stimulators или выбрать пункт контекстного меню c тем же названием. Для каждого сигнала необходимо установить его тип и силу. Тип устанавливается в поле Stimulator type окна Stimulators. Возможные типы сигналов перечислены ниже.
  • Clock — сигнал в виде последовательности одинаковых импульсов. Параметры (частота импульсов, время начала) устанавливаются в полях на появившейся картинке.
  • Custom — позволяет задать произвольную форму сигнала.
  • Formula — форма сигнала задается формулой. Формула выглядит следующим образом: значение [ время {, значение время}[ -r период]]. Например, формула 0 0, 1 80 ns -r 100 ns означет, что сигнал начинается с логического "0", а с 80-й нс — переходит к логической "1", на 100-й — опять переходит в "0" и т.д.
  • Hotkey — позволяет привязать к сигналу клавишу, при нажатии которой сигнал будет переключаться. Для этого надо в поле Press new hotkey ввести желаемую клавишу. Задействованные клавиши и переключаемые ими значения можно посмотреть, выбрав закладку Hotkeys.
  • Predefined — позовляет воспользоваться шаблонами, уже определенными в системе Active-VHDL.
  • Value — позволяет задать конкретное значение для сигнала.
Рис. 6.
Удобнее всего будет, если вы выберите для всех трех входных сигналов тип Hotkey. Силу (Force) для всех сигналов следует определить как Override.
После того, как вы определили все входные сигналы, можно приступать к моделированию. Установите желаемый шаг модельного времени и нажмите кнопку Run For. Для выбранного промежутка времени будет построена временная диаграмма. Меняя с помощь горячих клавиш значения входных сигналов и наблюдая за выходным, сделайте вывод о правильности работы элемента.
Рис. 7.
5.Повторите процесс моделирования для всех элементво нижнего уровня (2И).
После того, как все элементы нижнего уровня созданы и промоделированы, можно создавать элементы верхних уровней. Покажем этот процесс на примере создания JK-триггера из элементов 3И-НЕ. Для этого откройте код, созданный New Design Wizard для триггера (аналогично тому, как это делается для элементов нижнего уровня) и структурно опишите архитектуру триггера. Повторите процедуру компиляции кода и построения временных диаграмм, как описано ранее. При этом не забудьте выбрать в качетсве верхнего уровня проектируемый элемент.
6.Так же, как в п.5 промоделируйте элемент самого верхнего уровеня — счетчик. При этом при построении временной диаграммы для всех входов, кроме CLK, выберите тип Hotkey, а для CLK — тип Clock с частотой, которая учитывает задержку, которую вы задали для элементов нижнего уровня.
Требования к отчету
Отчет по лабораторной работе должен содержать схемы моделируемых элементов и временные диаграммы, полученные в результате проведения моделирования в системе Active-VHDL.
Список литературы
1. Армстронг Дж.Р. Моделирование цифровых систем на языке VHDL: Пер. с англ./М.: Мир, 1992.-175 с.
2. Active-VHDL Series. Getting Started Guide.- Poland: Aldec, Inc.,1998.-202 pp.
3. http://www.aldec.com/


Основы CALS-технологий
Глава 1. Задачи CALS-технологий
1.1. Этапы жизненного цикла изделий и промышленные автоматизированные системы
1.2. Основные положения и принципы CALS
1.3. Историческая справка
1.4. Автоматизированные системы делопроизводства
1.5. Управление проектами
1.6. Управление конфигурацией
1.7. PDM — управление проектными данными
1.8. Электронная цифровая подпись
1.9. Управление качеством
1.10. Интегрированная логистическая поддержка
1.11. Анализ логистической поддержки
1.12. Системы технического обслуживания и ремонта
1.13. Материально-техническое обеспечение
1.14. Языки разметки
1.15. Интерактивные электронные технические руководства
Тест: Управление конфигурацией
Глава 2. CALS-стандарты
2.1. Обзор CALS-стандартов
2.2. Структура стандартов STEP
2.3. Стандарт DEF STAN 00-60
2.4. Стандарт AECMA S2000M
2.5. Стандарт AECMA S1000D
2.6. Стандарты управления качеством промышленной продукции
Глава 3. Язык Express
3.1. Структура моделей на языке Express
3.2. Типы данных в языке Express
3.3. Язык Express: Супертипы и подтипы
3.4. Язык Express: ограничения
3.5. Язык Express: процедуры и функции
3.6. Организация в STEP информационных обменов
3.7. Express-X
3.8. Расширения языка Express
3.9. Интегрированные ресурсы в STEP
3.10. Прикладные протоколы STEP
3.11. Примеры моделей на языке Express
3.12. Программное обеспечение CALS-технологий
Тест: Интерактивные электронные технические руководства
Тест: Обменный файл
Тест: Язык Express (пример 1)
Тест: Язык Express (пример 2)
Тест: Express и Express-G (пример 3)
Тест: Express и Express-G (пример 4)
Тест: Express и Express-G (пример 5)
Тест: Express и Express-G (пример 6)
Тест: Express и Express-G (пример 7)
Тест: Прикладные протоколы в STEP
Лабораторный практикум
Изучение языка Express на основе программного комплекса EDM
Использование языка VHDL для моделирования цифровых устройств на регистровом уровне


Учебный курс
Основы CALS-технологий

Информационная поддержка изделий (ИПИ или CALS) является современной методологией автоматизации различных этапов жизненного цикла промышленной продукции (ЖЦП). CALS-технологии обеспечивают интеграцию автоматизированных систем проектирования и управления производстом за счет создания единого информационного пространства и доступа к нему всех участников ЖЦП в нужное врем и в нужном месте.

В пособии изложены основные положения CALS-технологий, охарактеризованы стандарты CALS, описан язык информационного взаимодействия систем Express.
Разработчик курса: д.т.н. проф. Норенков И.П.

Содержание