close

Вход

Забыли?

вход по аккаунту

?

Solnicev

код для вставкиСкачать
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
Федеральное государственное автономное образовательное учреждение
высшего профессионального образования
САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
АЭРОКОСМИЧЕСКОГО ПРИБОРОСТРОЕНИЯ
Р. И. Сольницев, Л. И. Гришанова
ВНЕДРЕНИЕ СИСТЕМ АВТОМАТИЗАЦИИ
ПРОЕКТИРОВАНИЯ
Учебное пособие
Санкт-Петербург
2014
УДК 681.5(075)
ББК 30.2-5-05я73
С60
Рецензенты:
доктор технических наук, профессор И. В. Герасимов;
доктор технических наук, профессор Г. И. Коршунов
Утверждено
редакционно-издательским советом университета
в качестве учебного пособия
Сольницев, Р. И.
С60
Внедрение систем автоматизации проектирования: учеб. пособие / Р. И. Сольницев, Л. И. Гришанова. – СПб.: ГУАП, 2014. – 109 с.
ISBN 978-5-8088-0982-6
Рассматриваются основы процесса внедрения систем автоматизации проектирования (САПР) в промышленности. Большое внимание уделено обследованию предприятия до начала внедрения или
модернизации САПР, изложена методика интеграции САПР с другими автоматизированными системами. Рассмотрены государственные и международные стандарты, а также программные средства,
применяемые при внедрении САПР.
Издание может быть рекомендовано к использованию в учебном
процессе по направлениям «Информатика и вычислительная техника», «Системный анализ и управление», а также для смежных направлений и специальностей.
УДК 681.5(075)
ББК 30.2-5-05я73
ISBN 978-5-8088-0982-6
© Сольницев Р. И., Гришанова Л. И., 2014
© Санкт-Петербургский государственный
университет аэрокосмического
приборостроения, 2014
ВВЕДЕНИЕ
Информационные технологии (ИНТЕХ) проектирования, производства и эксплуатации являются в настоящее время и в ближайшем будущем необходимым инструментом создания промышленных изделий в условиях острой конкуренции между предприятиями. Системы автоматизации проектирования (САПР) являются
основной составляющей этих технологий.
Разработка обеспечений и компонентов САПР достаточно полно
представлена в учебной литературе (например, [1–4]). Значительно
меньшее внимание уделяется процессу внедрения САПР. Особенно
это стало заметным в последнее время, когда технико-экономическая эффективность САПР диктует обязательность выбора объектов автоматизации, оценки целесообразности капитальных вложений, масштабов и возможностей конкретных внедрений инструментов ИНТЕХ проектирования и производства, нормирования и
унификации этих инструментов.
Внедрение САПР является достаточно сложным технико-экономическим процессом. Большое значение имеет в этом процессе
концептуальный подход к внедрению. Существует принципиальное отличие процесса внедрения на предприятиях с установившейся многолетней традицией проектирования и производства
и вновь создаваемых предприятиях. В первом случае основной
подход – внедрение инструментария проектировщика по схеме
«инструмент за инструментом», «по месту и по делу» [1]. Естественно, при этом должна быть разработана общая схема автоматизации процессов проектирования и производства. Во втором
случае уже при создании проектно-производственного предприятия закладывается соответствующая САПР, которая подлежит
такому же проектированию и производству, как любое сложное
изделие.
Системы автоматизации проектирования на современном витке
развития этого направления тесно связаны со средствами автоматизации всего жизненного цикла изделия (ЖЦИ) от предварительных согласований до утилизации. Эта связь может быть достаточно
сильной, вплоть до полного объединения с автоматизированными
системами научных исследований (АСНИ) и автоматизированными системами технологической подготовки производства (АСТПП).
Многочисленные обратные связи от процессов эксплуатации изделия и, естественно, маркетинга и менеджмента к проектированию
и производству – также характерное явление современности. Учет
3
этих связей становится обязательным при внедрении САПР, что
собственно и лежит в основе так называемых CALS-технологий.
Следует отметить еще одну характерную черту развития САПР
в настоящее время – востребованность на рынке отдельных подсистем САПР (инструментов проектировщика) вместо тяжелых и
средних САПР (Unigraphics, Pro/Engineer, SolidWorks, SolidEdge
и т. д.), что объясняется появлением малых и средних проектнопроизводственных предприятий.
Многочисленные средства моделирования бизнес-процессов
в нотациях SADT, IDEF, UML и новейшие – IBO, Social IBO1, а также средства управления и динамического сопровождения проектов, например MS Project, обязательно требуют формирования исходных данных (задачи, ресурсы, планирование и многое другое,
вплоть до традиций конкретного предприятия). Эти данные можно
получить только при обследовании предприятия в соответствии
с методиками, обеспечивающими эффективность внедрения.
В предлагаемом учебном пособии излагаются основные подходы
и средства, составляющие методологию внедрения САПР. Важнейшими направлениями в этом отношении являются:
обязательное обследование предприятия до внедрения САПР
с целью выявления проектных и производственных процедур,
нуждающихся в автоматизации, «не поддающихся» процедур или
малоэффективных инструментов ИНТЕХ;
интеграция САПР с современными ИНТЕХ управления проектированием и производством (АСУП), в особенности документооборотом и автоматизированными системами эксплуатации;
оценка технико-экономической эффективности САПР на всех
этапах жизненного цикла изделия в сочетании с общегосударственными и международными нормами и стандартами.
1 см. http://clado.livejournal.com/
4
1. ОСНОВНЫЕ ОПРЕДЕЛЕНИЯ И ПОНЯТИЯ
1.1. Назначение и построение САПР
Сложность промышленных изделий, постоянное ужесточение
требований к проектам, чрезвычайно высокая цена ошибочных проектных решений входит в противоречие с традиционными инструментами, технологией и организацией проектирования. Достаточно
давно признано, что выходом из положения является разработка и
внедрение нового набора инструментов (инструментария проектировщика) – системы автоматизированного проектирования (САПР) при
использовании новой информационной технологии проектирования.
Понятие «технология автоматизированного проектирования»
нужно рассматривать как последовательность проектных процедур,
выполняемых в определенном порядке с привлечением инструментария проектировщика, который позволяет преобразовывать описание
проектируемого объекта на проблемно-ориентированном языке в законченную совокупность проектных документов при заданных показателях эффективности проекта. В это понятие включаются также
знания о всех проектных процедурах, связях между ними, средствах
реализации, необходимых для достижения цели проектирования.
Дополним введенные понятия основными определениями в области проектирования.
Проектирование – процесс создания технической документации, опытных образцов и моделей объекта, необходимых и достаточных для его изготовления на заводе.
Проектная процедура – совокупность проектных операций над
исходными данными, выполнение которых заканчивается проектным решением.
Проектная операция – действие или совокупность действий проектировщика, составляющих часть проектной процедуры и заканчивающихся получением фрагмента проектного решения.
Проектное решение – промежуточное или конечное описание
объекта проектирования, необходимое и достаточное для завершения проектной процедуры.
Проект – совокупность проектных документов (технической документации) в соответствии с установленным перечнем ЕСТД, а
также опытный образец.
Средства проектирования – это инструменты, орудия труда проектировщика: «старинные» – карандаш, бумага, макеты, чертежные столы; «новые» – средства САПР.
5
САПР – это инструментарий проектировщика (разработчика,
конструктора, технолога, испытателя), включающий в себя техническое, математическое, лингвистическое, программное, информационное, методическое и организационное обеспечения,
предназначенный для автоматизации проектирования объектов на
конкретном предприятии на всех этапах – от выдачи технического
задания до передачи проекта заводу-изготовителю.
Содержащийся в понятии САПР термин «система» (целое, составленное из частей) означает совокупность частей, связанных с общим
назначением. Отличительный признак системы – ее целостность,
т. е. наличие такой совокупности свойств, которой нет ни у одной из
ее частей. САПР строится из подсистем, т. е. отдельных инструментов проектировщика, соответствующих конкретным процедурам.
Подсистема (инструмент) САПР – это выделенная по признакам
соответствующей проектной процедуры часть САПР, обеспечивающая получение законченных проектных решений и соответствующих проектных документов.
Подсистема САПР состоит из компонентов САПР, под каждым
из которых понимается элемент обеспечения САПР, выполняющий
определенную функцию в подсистеме. С точки зрения разработчика
САПР каждый инструмент САПР – сложная многокомпонентная
конструкция, функционирование которой он обязан досконально
знать. С точки зрения пользователя это удобный инструмент для
выполнения проектных процедур. Это отличие – принципиальное!
На рис. 1.1 показана структура САПР, ориентированная на четыре категории пользователей (разработчиков, конструкторов,
технологов, испытателей).
Система автоматизированного проектирования
Инструментарий
разработчиков
Подсистема САПР
К1
Инструментарий
конструкторов
Инструментарий
технологов
Подсистема САПР
К2
К3
…
…
Кn
Компоненты САПР
Рис. 1.1. Структура САПР
6
Инструментарий
испытателей
Подсистема САПР
Приведем определения обеспечений САПР, из компонентов которых формируются инструменты проектировщика.
Техническое обеспечение САПР – это совокупность взаимосвязанных и взаимодействующих аппаратных средств ЭВМ: ЦВМ,
АВМ, устройств ввода-вывода, в том числе алфавитно-цифровых и
графических дисплеев (АЦД и ГД), графопостроителей (ГП) и печатающих автоматов (ПА), интеллектуальных терминалов, динамических моделирующих стендов, на которых осуществляется автоматизированное проектирование.
Математическое обеспечение – совокупность математических
моделей, математических методов и алгоритмов, необходимых для
выполнения автоматизированного проектирования.
Программное обеспечение – совокупность программ, описаний
и инструкций, в том числе пакетов прикладных программ, составленных на основе математического обеспечения и предназначенных для реализации проектных процедур на ЭВМ.
Лингвистическое обеспечение – совокупность языков программирования, языков проектировщиков и правил формализации
этих языков, представленных в форме, удобной для применения
в составе САПР.
Информационное обеспечение – совокупность сведений, представленных на машинных носителях информации, в том числе баз
данных (БД) и баз знаний (Б3), содержащих нормативы, справочные данные, типовые проектные решения, закономерности и правила проектного процесса, которые необходимы для выполнения
автоматизированного проектирования.
Методическое обеспечение – это совокупность документов, устанавливающих правила и инструкции по эксплуатации инструментов (подсистем) САПР и их компонентов.
Организационное обеспечение – совокупность документов, устанавливающих организационную структуру САПР, формы и порядок прохождения проектных документов, изготовляемых средствами САПР; порядок взаимодействия должностных лиц, подразделений САПР и отделов проектной организации.
Из компонентов этих обеспечений и строятся инструменты (подсистемы) САПР. Каждый инструмент включает компоненты всех
семи видов обеспечений (рис. 1.2). Построение такого инструмента –
сложный процесс, аналогичный созданию любого другого современного объекта промышленного производства. Интеграция САПР
с другими средствами ИНТЕХ проектирования и производства обеспечивается современными средствами связи инструментов проек7
Информационное
Лингвистическое
Программное
Математическое
Крт1
р
Км1
р
Кп1
Крл1
р
Ки1
Кр2
К5р
Крт2
р
Км2
р
Кп2
Крл2
р
Ки2
К3р
К6р
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Компоненты
инструментария
конструктора
Техническое
Кр4
К1к
Кк4
Крт1
Ккм1
Ккп1
Ккл1
Кки1
Кк2
К5к
Ккт2
Ккм2
Ккп2
Ккл2
Кки2
К3к
Кк6
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Компоненты
инструментария
технолога
Организационное
Компоненты
инструментария
разработчика
К1р
К1т
К4т
Ктт1
т
Км1
т
Кп1
Ктл1
т
Ки1
К2т
К5т
Ктт2
т
Км2
т
Кп2
Ктл2
т
Ки2
К6т
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Компоненты
инструментария
испытателя
Виды
компонентов
Методическое
Виды обеспечений
К1и
Ки4
Кит1
Ким1
Кип1
Кил1
Кии1
Ки2
К5и
Кит2
Ким2
Кип2
Кил2
Кии2
Ки6
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Рис. 1.2. Структура компонентов инструментария проектировщика
8
тировщика (подсистем САПР) с АСТПП, АСУП (PDM, PLM …) и т. д.
Внедрение САПР обеспечивает также применение на этапе обследования предприятия средств моделирования бизнес-процессов в нотациях SADT, IDEF, DFD, ARIS, в том числе на языке UML (см. гл. 5).
В настоящее время на рынке имеется большое количество включенных в САПР пакетов прикладных программ, использующихся
на стадии конструкторского проектирования, а часть из них также
на стадиях научных исследований и технологической подготовки
производства.
В машиностроении традиционно продукты САПР делятся на
три класса: тяжелые, средние и легкие (табл. 1.1). Такая классификация сложилась исторически, и хотя уже давно идут дискуссии
о том, что грани между классами вот-вот сотрутся, они остаются,
так как системы по-прежнему различаются и по цене, и по функциональным возможностям.
Предлагаются также специализированные САПР, примеры которых приведены в табл. 1.2.
Следует отметить, что в настоящее время имеется тенденция
выпуска отдельных инструментов САПР «россыпью», которые
Таблица 1.1
Классификация пакетов САПР
Класс САПР
Продукт
Unigraphics NX
Тяжелый
CATIA
Pro/Engineer
SolidEdge
SolidWorks
Inventor и Mechanical Desktop
Cimatron
think3
CadKey
Средний
PowerSolutions
КОМПАС
T-Flex
КРЕДО
AutoCAD
SurfCAM 2D
DataCAD
Легкий
IntelliCAD
TurboCAD
Компания
UGS PLM Solutions (EDS)
Dassault Systemes/IBM
PTC
UGS PLM Solutions (EDS)
SolidWorks
Autodesk
Cimatron
Think3 S.p.A.
CadKey
Delcam
Аскон
Топ Системы
НИЦ АСК
Autodesk
Surfware
DataCAD
CADopia
IMSI
9
Таблица 1.2
Специализированные САПР
Промышленное
проектирование
Строительное
проектирование
(железобетон)
Архитектурное
проектирование
AutoPlant
Rebis (принадлежит
фирме Bentley)
Robot Millennium
RoboBAT
Architectural Desktop
Autodesk
используются вместо тяжелых или средних систем, например
NanoCAD, предназначенная для решения конкретных технических задач, таких как разработка электрической проводки, прокладки труб, или ArchiCAD – графический программный пакет
для архитекторов, предназначенный для проектирования архитектурно-строительных конструкций.
Создание САПР во многом аналогично проектированию и изготовлению любого изделия. Во всех случаях выбирается структура,
состав основных элементов, проводится детальная разработка этих
элементов, проектирование, изготовление, отладка, испытание,
выпуск соответствующей технической документации. Разработка САПР проводится в соответствии с ГОСТ 24601-86 и включает
в себя 8 стадий: предпроектные исследования, техническое задание (ТЗ), аван-проект (АП), эскизный проект, технический проект,
рабочий проект, комплексирование, отладка и испытания, ввод
в действие. Стадия – это структурно-законченная часть процесса
создания САПР, которая охватывает совокупность работ, ограниченных двумя смежными моментами времени, характеризует
определенное состояние процесса, параметры которого отражают
описание САПР в целом или ее подсистемы; завершается контролем выполнения работ и утверждением документов, в которых изложены результаты соответствующих работ.
К настоящему времени и в отечественной, и в зарубежной практике уже достаточно четко определилась общая последовательность работ по созданию САПР [3–6]. Эта последовательность приведена в табл. 1.3, где отмечено присутствие тех или иных этапов
работ по автоматизации проектирования на различных стадиях
создания САПР.
Общая технология построения систем автоматизации проектирования включает в себя указанные в табл. 1.3 типовые этапы
10
Таблица 1.3
Стадии и этапы создания САПР
Этапы создания САПР
Определение области применения,
целей и назначения
Описание объекта проектирования
Описание процесса проектирования
Разработка структуры и схемы
функционирования
Разработка альтернативных и
выбор рационального варианта
Технико-экономическая оценка
Планирование процесса создания
Разработка технического
обеспечения
Разработка математического
обеспечения
Разработка программного
обеспечения
Разработка лингвистического
обеспечения
Разработка информационного
обеспечения
Разработка методического
обеспечения
Разработка организационного
обеспечения
Реализация САПР
Обеспечение использования и
развития САПР
Стадии создания САПР
Рабочий
Эскизный
Предпроектные
исследования, и технический проект
проекты
ТЗ и АП
+
+
-
+
+
+
+
-
+
+
-
+
+
-
+
+
+
+
-
-
+
+
-
+
+
-
+
+
-
+
+
-
-
+
-
+
+
-
-
+
-
-
+
работ, обязательное выполнение которых в тех или иных комбинациях необходимо для осуществления соответствующих стадий создания САПР.
В методологическом плане первые три из перечисленных
в табл. 1.3 этапов работ имеют много общего. Их выполнение опирается на системный подход к рассмотрению как объектов проектирования, так и самих средств автоматизации проектирования.
Разработка структуры и схемы функционирования, разработка
11
альтернативных вариантов САПР, технико-экономическая оценка САПР, планирование процесса создания САПР тесно связаны
между собой. Эти этапы работ, предшествуя детальной разработке
основных компонентов САПР, образуют достаточно самостоятельный цикл исследований в процессе создания САПР, носит своей
конечной целью определение рационального варианта создаваемой
системы, оценку ее характеристик и составление требований к основным компонентам.
Если рассматривать САПР как сложный объект проектирования, то в соответствии с принятым определением жизненного цикла изделия [3], на рис. 1.3 представлены фазы создания САПР в соответствии с традиционной терминологией.
Рассмотрим более детально фазы создания САПР.
Анализ потребности в разработке системы и ее подсистем тесно
связан с маркетингом. Целью маркетинговых работ при создании и
функционировании САПР является реализация целенаправленной
производственно-сбытовой стратегии, ориентированной на постоянную модернизацию (совершенствование) САПР, освоение новых технологий, ускорение процессов обновления выпускаемой с помощью
САПР продукции, на гибкую и эффективную рыночную политику.
Маркетинг в условиях САПР представляет собой концепцию
управления процессом проектирования на предприятии [7], пред-
Фазы
1. Анализ потребности в разработке
и совершенствовании САПР
и ее частей. Требования к системе
1. Анализ потребности
в новом классе
систем автоматизации
2. Предпроектные исследования.
Оценка осуществимости требований,
разработка технического задания
3. Проектирование САПР
и ее составных частей
Исходные данные
для проектирования
нового класса систем
4. Внедрение САПР, сопровождение.
Гарантийное обслуживание
5. Промышленная эксплуатация,
модернизация и развитие системы
6. Исключение неэффективных
подсистем и компонентов САПР
Время
Рис. 1.3. Фазы жизненного цикла САПР
12
полагающую тщательный учет на основе использования высокопроизводительных ЭВМ и методов управления процессами, происходящими на рынке, для принятия эффективных управленческих
решений и получения максимальной прибыли.
Цели и задачи обследования связаны с оценкой возможности
внедрения САПР на предприятии. Главной целью такого обследования является разработка требований к САПР, выбор принципиальных технических решений и разработка программы внедрения
САПР на основании функционально-стоимостного анализа различных вариантов реализации. Соответственно, на этой стадии необходимо рассмотреть значительный комплекс взаимосвязанных
вопросов, охватывающих экономические, организационные, технологические и программно-аппаратные аспекты проблемы совершенствования САПР. Предполагаемые технические решения и их
экономические оценки должны носить вариантный характер с учетом специфики данного предприятий, но опираться на единую концепцию построения САПР как инструментария проектировщика.
Результатом проведения работ на фазе проектирования является комплект проектной документации на САПР (проект совершенствования САПР).
Состав и содержание проектной документации устанавливается
нормативно-техническими документами, действующими в стране.
Внедрение подсистем САПР (совершенствование САПР) включает этап «Опытная эксплуатация и ввод подсистем САПР в действие».
Проведению опытной эксплуатации предшествует составление
акта завершения подготовки к вводу в действие отдельных подсистем САПР, выпуск приказа руководителя предприятия с указанием состава приемочной комиссии и программы опытной эксплуатации, согласованной с разработчиком. В программе указываются
условия и порядок функционирования подсистем САПР, число
прогонов при выполнении проектных процедур, порядок устранения недостатков, выявленных в процессе опытной эксплуатации,
продолжительность опытной эксплуатации.
По результатам опытной эксплуатации специальная комиссия
принимает решение о проведении приемосдаточных испытаний
подсистем САПР и САПР в целом.
Промышленная эксплуатация и сопровождение САПР представляет собой процесс выявления целесообразных доработок действующей САПР и ее подсистем непосредственно в процессе эксплуатации.
Сопровождение и совершенствование САПР обеспечивается
в течение срока, оговоренного в договоре (контракте) на создание и
13
совершенствование САПР, и осуществляется разработчиком и/или
заказчиком.
После указанного срока продолжение этих работ должно осуществляться заказчиком с привлечением разработчика на основе
дополнительного договора (контракта) за фактически выполненные услуги.
На фазе «Исключение из системы неэффективно работающих
подсистем САПР и замена компонентов САПР» соответствующие
операции в основном реализуются заказчиком системы после некоторого срока промышленной эксплуатации.
Рекомендуется на этой фазе силами заказчика провести анализ
функционирования системы. Пользователи системы и отдельных
ее частей в процессе эксплуатации вносят предложения по совершенствованию отдельных подсистем САПР или их исключению и
замене на другие. Такая работа в связи с произведенными ранее
затратами должна проводиться в порядке, который не затрагивает
хорошо функционирующих частей системы.
1.2. Процесс проектирования и принципы
его автоматизации
В соответствии с ГОСТами [5, 6, 8] выделяют следующие стадии
проектирования: предпроектные исследования (ПИ), техническое
задание (ТЗ), техническое предложение (ПТ), эскизный проект
(ЭП), технический проект (ТП), рабочее проектирование (РП), испытания (И) и внедрение (В). Этап проектирования – это составная
часть любой из стадий проектирования, сводящаяся к выполнению
проектных процедур (операций) (рис. 1.4).
На стадиях предпроектных исследований, технического задания
и технического предложения, называемых также предварительным
проектированием или стадиями научно-исследовательских работ
(НИР), на основании изучения потребностей общества в создании
новых изделий, научно-технических достижений в области приборостроения и смежных с ней областях науки и техники, имеющихся ресурсов и т. п., определяют назначение, основные принципы
построения проектируемого объекта и формулируют техническое
задание на его проектирование. Результатом выполнения предварительного проектирования является техническое предложение.
На этапе эскизного проектирования выполняется всесторонняя
проработка основных принципов и положений, определяющих
14
Процесс проек
тирования
ПИ
ТЗ
ПТ
ЭП
ТП
РП
И
В
Э1
Э2
Э3
…
Эn
ПП 1
ПП 2
ПП 3
…
ПП n
Проектные процедуры
ПО1
ПО2
ПО3
…
ПОn
Проектные операции
Этапы
Рис. 1.4. Структура процесса проектирования
функционирование объекта проектирования, и разрабатывается
его эскизный проект.
На стадии технического и рабочего проектирования выполняется тщательная проработка всех схемных, конструкторских и технологических решений. Результатом выполнения этапов на этой
стадии является технический и рабочий проекты.
На стадиях изготовления опытной партии и серийного производства изделий в процесс проектирования входят этапы изготовления опытных образцов и выпуск установочной серии изделия, по
результатам испытаний которого вносятся все необходимые изменения в проектную документацию.
В табл. 1.4 приведены стадии и этапы разработки проектной документации. Документы проекта подразделяются на проектные
(техническое предложение, эскизный проект и технический проект) и рабочие (рабочая документация).
Рассмотрим теперь понятие объекта проектирования, как изделия, поступающего в эксплуатацию. Под изделием понимается
предмет или набор предметов производства, подлежащих изготовлению на предприятии по выполненной на них конструкторской
документации.
Например, изделиями бортового приборного оборудования являются пилотажно-навигационные комплексы, инерциальные систе15
Таблица 1.4
Стадии и этапы разработки проектной документации по ГОСТ 2.103
Стадии разработки
Разработка
технического
предложения
Разработка
эскизного
проекта
Разработка
технического
проекта
Этапы работ
Подбор материалов.
Разработка комплекса документов технического
предложения по результатам анализа технического
задания с присвоением документам литеры «П».
Изготовление и испытание макетов.
Рассмотрение и утверждение технического
предложения
Разработка комплекта документов эскизного проекта
с присвоением документам литеры «Э».
Изготовление и испытание макетов.
Рассмотрение и утверждение эскизного проекта
Разработка комплекта документов технического
проекта с присвоением документам литеры «Т».
Изготовление и испытание макетов.
Рассмотрение и утверждение технического проекта
Разработка
рабочей документации
а) опытного
Разработка конструкторских документов,
образца (опытной предназначенных для изготовления и испытания
партии)
опытного образца (опытной партии).
Изготовление и заводские испытания опытного
образца (опытной партии).
Корректировка конструкторских документов по
результатам изготовления и заводских испытаний
опытного образца (опытной партии) с присвоением
конструкторским документам литеры «О».
Государственные, межведомственные, приемочные
и другие подобные испытания опытного образца
(опытной партии).
Корректировка конструкторских документов по
результатам государственных, межведомственных,
приемочных и других подобных испытаний
опытного образца опытной партии с присвоением
конструкторским документам литеры «О».
При последующих повторных изготовлениях и
испытаниях опытного образца (опытной партии) и
соответствующей корректировке конструкторских
документов им присваивают соответственно литеры
«О1» «О2» и т. п.
16
Окончание табл. 1.4
Стадии разработки
Этапы работ
б) установочных Изготовление и испытание установочной серии.
серий
Корректировка конструкторских документов по
результатам изготовления, испытания и оснащения
технологического процесса ведущих составных частей
изделия установочной серии с присвоением конструкторским документам литеры «А»
в) установивше- Изготовление и испытание головной (контрольной)
серии.
гося серийного
Корректировка конструкторских документов по
или массового
производства
результатам изготовления головной (контрольной)
серии, с присвоением литеры «Б» конструкторским
документам, окончательно отработанным и
проверенным в производстве изготовлением изделий
по зафиксированному и полностью оснащенному
технологическому процессу
мы навигации, системы индикации, авиационное бортовое электрооборудование, датчики, первичные преобразователи информации,
бортовые цифровые вычислительные машины и другая радиоэлектронная аппаратура (РЭА), устанавливаемая на борту различных
летательных аппаратов. Большинство приборов и систем имеют
цифровую обработку информации, построены по модульному принципу, имеют несколько конструктивных исполнений.
В блоках обработки информации используются большие интегральные схемы (БИС) и микросборки частного применения.
В блоках систем применяют типовые цифровые, аналоговые и
цифроаналоговые интегральные схемы, бескорпусные элементы
для микросборок, программно-логические матрицы, микросхемы
«прожигаемой» памяти, микропроцессоры, печатные платы с тонкопроводным монтажом, многослойные, рельефные. В приборах
имеются узлы электромеханики. Электромонтаж в приборах выполняется с помощью гибко-жестких плат, ленточных проводов,
объемных проводников. Как следует из предыдущего, изделие не
может быть изготовлено без проектной (конструкторской, технологической, сопровождающей) документации.
Единая система конструкторской документации (ЕСКД) устанавливает единый порядок разработки, выполнения, оформления,
согласования, внесения изменений, учета и хранения конструкторской документации.
17
Номенклатуру конструкторских документов, разрабатываемых
на изделие, определяют в совокупности два фактора: вид изделия
(деталь, сборочная единица, комплекс, комплект) (рис. 1.5) и уже
изложенные стадии разработки.
Деталь представляет собой изделие, изготовленное из однородного по наименованию и марке материала без применения сборочных операций. К деталям, например, относятся литой корпус прибора, печатная плата, отрезок провода или кабеля заданной длины.
Сборочная единица представляет собой изделие, составные части которого подлежат соединению между собой на предприятииизготовителе сборочными операциями (свинчиванием, сочленением, клепкой, сваркой, пайкой, развальцовкой, склеиванием, сшивкой, укладкой и т. п.). К сборочным единицам, например, относятся разнообразные узлы, блоки, агрегаты и другие составные части
сложных изделий.
Комплекс образуют два и более специфицированных изделия,
не соединенных на предприятии-изготовителе сборочными операциями, но предназначенных для выполнения взаимосвязанных
эксплуатационных функций. Каждое из специфицированных изделий, входящих в комплекс, служит для выполнения одной или
нескольких основных функций, установленных для всего комплекса. Комплексами, например, являются: вычислительные, навигационные, измерительные, управляющие установки; летательные
аппараты с бортовым приборным оборудованием. В комплекс моСпецифицированное изделие
Сборочные
единицы
Комплексы
Комплекты
Комплексы
Сборочные
единицы
Детали
Комплекты
Сборочные
единицы
Детали
Комплекты
Сборочные
единицы
Детали
Комплекты
Рис. 1.5. Классификация изделий и их составных частей на виды
18
гут также входить детали, сборочные единицы и комплекты, предназначенные для выполнения вспомогательных функций, например: детали и сборочные единицы, предназначенные для монтажа
комплекса на месте его эксплуатации; комплект запасных частей,
укладочных средств, тары и другие.
Комплект образуют два и более изделия, не соединенных на
предприятии-изготовителе сборочными операциями и представляющих набор изделий, имеющих общее эксплуатационное назначение вспомогательного характера. К комплектам, например, относятся комплект запасных частей, комплект инструмента и принадлежностей, комплекс измерительной аппаратуры, комплект
упаковочной тары.
Состав конструкторской документации на изделие включает
следующие виды документов: чертеж – детали, сборочный, монтажный; чертеж-схема; спецификация; техническое описание;
ведомости; пояснительная записка и др. Текстовые конструкторские документы могут содержать сплошной текст (техническое
описание, паспорта, пояснительные записки, инструкции и т. п.)
и текст, разбитый на графы (спецификации, ведомости, таблицу и
др.). Графические конструкторские документы содержат в основном графическое изображение изделия и (или) его составных частей, взаимного расположения и функционирования этих частей,
их внутренних и внешних связей.
Основными конструкторскими документами являются: для деталей – чертеж детали; для сборочных единиц, комплектов и комплексов – спецификация.
Контрольные вопросы
1. Что означают понятия «информационные технологии» и
«САПР»?
2. В чем состоит назначение САПР?
3. Каким образом строится процесс проектирования и каковы
принципы его автоматизации?
4. Какие составляющие включают основные подсистемы и компоненты САПР?
5. Из каких этапов состоит процесс построения САПР?
6. В чем заключается процесс внедрения САПР?
19
2. ОБСЛЕДОВАНИЕ ПРЕДПРИЯТИЯ
ДО ВНЕДРЕНИЯ САПР
2.1. Обследование проектно-производственного
предприятия
Традиционный процесс проектирования изделий на ряде предприятий может быть рассмотрен как система, состоящая из двух
подсистем: управляющей и управляемой. Функционирование систем осуществляется за счет управляющих воздействий, которые
формируются на основе показателей качества, получаемых в результате разработки ТЗ (рис. 2.1).
На схеме (см. рис. 2.1) приняты следующие условные обозначения: 1 – управляющая подсистема; 2 – управляемая подсистема;
X0 – исходная информация; X – информация, представленная
технической документацией и опытным образцом объекта проектирования; Y1-2 – общее управляющее воздействие; Y1-2-2, Y1-2-3,
Y1-2-4, Y1-2-5, Y1-2-6 – частные управляющие воздействия; Q1-2 –
общая информация о проектировании; Q1-2-2, Q1-2-3, Q1-2-4, Q1-2-5,
Q1-2-6 – частная информация о проектировании.
Управление разработкой проекта рассматривается как целевое
воздействие, при котором объект из множества возможных состояний переходит в такое, которое соответствует заданной цели проектирования.
Х0
1
ɉɂ
3
ТЗ
2
Q1-2
Y1-2
2
ɗɉ
ɉɌ
2
1
Y1-2-1
Ɍɉ
Q2-1-1
Y1-2-2
Ɋɉ
3
Q2-1-2
Y1-2-3
ɂ5
4
Q2-1-3
Y1-2-4
Q2-1-4
Y1-2-5
ȼ6
Q 2-1-5
Y1-2-6
Х
Рис. 2.1. Структурно-информационная схема процесса
проектирования изделия
20
Q2-1-6
Под целью проектирования понимается разработка объекта
с установленными качественными и количественными характеристиками. Постановка целей проектирования связана с формированием качества проектируемого объекта, уровень которого не должен быть ниже, чем у существующих объектов.
К целям и задачам проектирования предъявляются такие требования, которые обеспечивали бы генерирование новых идей и переработку достаточного объема информации, снижающего неопределенность принятия решения. Установленные цели используются
для определения критериев оценки выбора оптимальных вариантов и средств их достижения.
Цели и задачи обследования связаны с оценкой возможности
внедрения САПР на предприятии. Главной целью такого обследования является разработка требований к САПР, выбор принципиальных технических решений и разработка программы внедрения
САПР на основании функционально-стоимостного анализа различных вариантов реализации. Соответственно, на этой стадии необходимо рассмотреть значительный комплекс взаимосвязанных
вопросов, охватывающих экономические, организационные, технологические и программно-аппаратные аспекты проблемы совершенствования САПР. Предполагаемые технические решения и их
экономические оценки должны носить вариантный характер с учетом специфики данного предприятий, но опираться на единую концепцию построения САПР как инструментария проектировщика.
При анализе автоматизации процесса проектирования определяют: количественные и качественные характеристики управляемой и управляющей подсистем (см. рис. 2.1), целесообразность внедрения САПР и степень подготовленности соответствующей подсистемы для ее дальнейшего совершенствования.
Системный анализ процесса проектирования с целью внедрения
САПР удобно подразделить на внешний и внутренний.
Основные задачи внешнего анализа управляемой подсистемы
следующие: определение ее организационной структуры и перечня проектных процедур, выполняемых в ней; выявление связей
между управляющей и управляемой подсистемами (см. рис. 2.1);
построение или корректировка модели управляемой подсистемы.
На этапе внутреннего анализа процесса проектирования (блок 2 на
рис. 2.1) решаются задачи построения моделей конкретных проектных
процедур, выделенных в качестве типовых, и определения их техникоэкономических характеристик с учетом всей входной и выходной документации, а также технологии проектирования и испытаний.
21
Рассмотрим более подробно внешний анализ. Первым шагом
внешнего анализа процесса проектирования является раскрытие
организационной структуры подразделений предприятия, занятых разработкой схем, конструкторским и технологическим проектированием, а также испытаниями опытных образцов, выявление
технико-экономической информации об имеющихся на предприятии технических средствах, программно-методических комплексах (ПМК) и пакетах прикладных программ. При этом прослеживаются пути прохождения информации от подразделения к подразделению и производится анализ этих путей для получения ответов
на следующие вопросы: какие данные передаются по линиям связи
локальной вычислительной сети, а какие с помощью документов
на бумажных и машинных носителях; фактические сроки передачи данных; какая информация не находит своих получателей
в других подразделениях предприятия.
Информационный анализ целесообразно разбить на следующие
операции: составление перечня проектируемых изделий в целом
и их составных частей; составление перечня проектных процедур
(операций); составление полного перечня входной и выходной информации; классификация информации; выявление избыточной
информации и дублирующих связей и циклов.
Техническую документацию классифицируют по следующим
видам: входная, выходная, вырабатываемая в результате выполнения проектных процедур, и внутренняя, используемая исключительно внутри подразделений предприятия.
Результаты анализа удобно заносить в специальные формы, которые затем могут быть закодированы и храниться в памяти ЭВМ.
В результате выполнения первого шага внешнего анализа получают структурную схему управляемой подсистемы с привязкой
к конкретным подразделениям предприятия.
На втором шаге внешнего анализа процесса проектирования
рассматриваются проектные процедуры, выполняемые в подразделениях предприятия. Определяются типы проектных процедур
и их количество по типам. Классификация проектных процедур
производится по признакам сходства результатов, получаемых при
выполнении различных проектных процедур, и характера исходных данных, а также сходства категорий проектировщиков (разработчики, конструкторы, технологи, испытатели).
Для составления перечня типовых проектных процедур анализируется проектная документация, входящая в проект. При этом
учитываются такие технико-экономические характеристики, как
22
временные и финансовые затраты, а также объемы и виды информации, переработанной в процессе выполнения проектной процедуры. На данном этапе обследования не требуется знать характеристики проектных процедур с точностью большей, чем это необходимо для их качественного предварительного сравнения по вкладу
в процесс проектирования.
Третьим шагом внешнего анализа является построение информационной модели системы проектирования, которая, по существу, представляет собой интегральное отображение результатов,
полученных на предыдущих шагах. На данном шаге целесообразно
использовать итеративный процесс последовательного приближения. Каждая итерация такого процесса связана с получением информации об объекте и процессе проектирования при различной
степени их дифференциации. Например, на первой итерации может быть получена информация об объекте в целом без его расчленения, на второй – о структурной схеме объекта, на третьей – о связях составных частей объекта и т. д.
Информационная модель также является основой для создания модели предметной области для обследуемого процесса проектирования.
Рассмотрим внутренний анализ. На этом этапе уточняется и детализируется информация о процессе проектирования, полученная на этапе внешнего анализа.
Первым шагом этапа внутреннего анализа является выделение
из каждой группы проектных процедур, полученных в результате
классификации на этапе внешнего анализа, типовых проектных
процедур, называемых проектными процедурами-представителями. Их выбор осуществляется, как правило, экспертным путем.
Затем на втором шаге для всех процедур-представителей определяются количественные и временные оценки либо экспертным путем,
либо методом хронометражных наблюдений. Последний позволяет
получить более точные данные о проектных процедурах по сравнению с методом экспертных оценок.
На этом этапе также уточняются структура и объем информации, используемой в процессе проектирования, в том числе и нормативно-справочной документации. Эти сведения впоследствии используются при разработке баз данных САПР.
Вся информация, полученная в результате внутреннего анализа, заносится в специальные формы, которые затем кодируются и
хранятся в памяти ЭВМ.
Таким образом, внутренний анализ завершается получением
интегральных характеристик по трудоемкости, длительности и
23
ряду других параметров выполнения типовых проектных процедур-представителей. На основе внешнего и внутреннего анализа
оценивается стратегия внедрения САПР. При этом выявляют:
объекты автоматизации (проектные процедуры);
состояние технических средств автоматизации проектных процедур;
уровень автоматизации проектных процедур;
уровень унификации и стандартизации конструкторско-технологических решений;
уровень автоматизации.
По результатам дается принципиальная оценка необходимости
разработки новой САПР либо совершенствования существующих
инструментов САПР. Оценивается уровень подготовленности предприятия по следующим показателям: обеспеченность кадрами специалистов, имеющих опыт работы с инструментами САПР; наличие необходимых технических средств САПР; возможность финансирования работ по САПР; соответствие организационной структуры предприятия условиям применения САПР.
Оценка стратегии внедрения САПР или совершенствования
имеющихся на предприятии инструментов САПР завершается
выдачей исходных данных для разработки технического задания
на внедрение САПР, которое формируется в соответствии с ГОСТ
34.602-89. Расчеты годового экономического эффекта от использования новой информационной технологии можно производить по
схемам, представленным в литературе [9, 10].
Плодотворность системного анализа процесса проектирования
в целях внедрения САПР в значительной степени зависит от организации работ по его обследованию (рис. 2.2).
Для проведения работ на данном этапе формируется рабочая
группа, которая руководствуется приказом руководителя предприятия, где определены: состав обследуемых подразделений, занятых проектированием конкретных изделий; состав исполнителей,
участвующих в обследовании; обязанности, выполняемые каждым
подразделением и исполнителем, проводящим обследование; сроки проведения обследования и порядок представления результатов
работы. Обследование выполняется специалистами подразделений
предприятия, в число которых включаются системотехники, разработчики САПР, опытные специалисты по соответствующему направлению техники. Для успешной работы рабочей группы ее членам должны быть присущи такие качества, как объективность, информированность, заинтересованность в результатах обследования.
24
Методика обследования
План-график
обследования
Цели, критерии, ограничения на создание САПР
Исходные данные и требования на создание САПР
Данные по всем видам
обеспечения САПР
Данные о проектировщиках
Данные о материальном и
финансовом обеспечении
Данные об объекте и
проектных процедурах
Опрос, анкеты
Изучение документации
Рабочая группа
Информационная модель
процесса проектирования
Научно-технический отчет
по результатам обследования
Процесс проектирования
Рис. 2.2. Схема организации выполнения системного анализа
процесса проектирования
В значительной степени качество результатов обследования зависит от подготовленности проектировщиков к замене старых инструментов проектирования новыми при выполнении проектных
процедур. Как справедливо отмечает один из ведущих специалистов в области автоматизации К. Кастеллани [11]: «Исключительно важно, чтобы люди непосредственно на своих рабочих местах
ощутили необходимость пересмотра процедур, которыми они пользуются. Тогда разработка задачи будет иметь серьезные шансы на
успех, поскольку совместный труд разработчиков и пользователей
будет протекать в обстановке сотрудничества и согласия, которая
крайне желательна для благополучного выполнения разработки».
При обследовании процесса проектирования рабочая группа собирает данные: общего характера по изделию в целом и его частям;
об организационной структуре проектных подразделений; о проектных процедурах; о всех семи видах обеспечений САПР; о проектировщиках.
Опыт проведения предпроектных исследований показывает,
что анализ процесса проектирования отдельного изделия, который
длится, как правило, продолжительное время, можно заменить интегральным анализом проектных процедур нескольких изделий,
25
обычно находящихся в разной стадии проектирования, за гораздо
меньший промежуток времени.
При проведении обследования процесса проектирования для
получения данных можно использовать следующие методы: изучение документов, анкетирование, устный опрос.
Метод изучения документов заключается в том, что необходимая информация выбирается из различных документов, отражающих деятельность проектных подразделений.
При анкетировании необходимые данные получают путем заполнения специалистами соответствующих форм (анкет).
Метод устного опроса состоит в получении данных путем проведения бесед с проектировщиками.
При проведении предпроектных исследований, как и на всех
последующих стадиях внедрения САПР, большое значение имеют планирование и управление. В частности, деятельность рабочей группы при обследовании организуется следующим образом:
1) подготовка и выпуск приказа по предприятию; 2) разработка,
согласование и утверждение план-графика обследования; 3) сбор
данных, проведение опроса; 4) анализ результатов обследования;
5) моделирование процесса проектирования, в том числе с внедренной САПР; 6) подготовка научно-технического отчета.
Рассмотрим применяемые методы обследования проектно-производственного предприятия, занимающегося проектированием
бортовых ЭВМ (БЦВМ) [2]. По результатам обследования строится
концептуальная модель процесса автоматизированного проектирования. Под концептуальной моделью предметной области понимают некоторую семантическую, знаковую систему, в которой однозначно и непротиворечиво интегрированы представления специалистов о данной предметной области. В данном случае для построения концептуальной модели процесса проектирования применен
принцип – от конечной цели, в качестве которой выступает получение полного состава технической документации проекта, т. е.
конструкторской, технологической и программной документации.
Функциональная схема процесса проектирования изделий в условиях функционирования САПР – это инвариантная к объектам,
упорядоченная совокупность информационно связанных проектных процедур и операций, приводящих к составлению описания,
необходимого для изготовления и эксплуатации в заданных условиях еще не существующего объекта.
В зависимости от того, в какой последовательности выполняются процедуры и этапы, различают два вида проектирования:
26
восходящее проектирование (снизу-вверх), которое применяется на
тех иерархических уровнях, на которых проектируются типовые объекты, предназначенные для использования в качестве элементов во
многих объектах на более высоких иерархических уровнях (например,
серийные микросхемы, стандартные ячейки матричных ВИС и т. п.);
нисходящее проектирование (от целого к его частям) применяется на тех уровнях, на которых проектируются объекты, ориентированные на использование в качестве элементов в одной конкретной системе.
Например, проектированию изделий приборостроения, в частности БЦВМ, свойствен итерационный характер, при котором приближение к окончательному результату осуществляется путем многократного выполнения одной и той же последовательности проектных
процедур с корректировкой для этой последовательности данных.
Итерации могут охватывать различные части процесса проектирования, включающие как несколько этапов, так и несколько операций.
Перечень уровней нисходящего проектирования от составления
технического задания до выпуска технической документации на
проект изделия содержит следующие вертикальные уровни проектного процесса.
Системное проектирование, включающее два подуровня: внешнее проектирование и структурное проектирование. При внешнем
проектировании выбираются основные направления схемотехнических, конструкторских и технологических решений, исходя из
заданного технического задания и на основе проведенного патентного поиска, накопленного опыта и творческих достижений разработчиков. Структурное проектирование заключается в выделении
основных функциональных частей БЦВМ и связей между ними,
выборе элементной базы.
Схемотехническое проектирование позволяет разработать принципиальные схемы отдельных частей БЦВМ и выбрать ее параметры. На этом уровне выполняется математическое моделирование
процессов функционирования реальной аппаратуры, что позволяет заменить макетирование этой аппаратуры и провести статистические исследования, связанные с анализом разброса параметров. Параметрический синтез дает возможность на основе модели
устройства выбрать числовые значения параметров устройства для
заданной разработчиком структуры.
Проектирование программного обеспечения, при выполнении
которого получают рабочие программы и конструкторскую документацию на микросхемы памяти.
27
Конструкторское проектирование, включающее выбор формы,
разработку конструктивов, их компоновку и размещение, трассировку соединений, изготовление конструкторской документации.
Технологическая подготовка производства и контроля, состоящая в разработке маршрутной и операционной технологии, управляющих программ для оборудования с ЧПУ, проверке изделия на
технологичность,
Комплексная отработка (отладка) включает в себя проверку образца изделия на работоспособность, на соответствие техническим
условиям, разработку эксплуатационной документации.
Схема концептуальной модели процесса проектирования изделий бортового приборного оборудования, построенного на базе
микропроцессорной техники, показана на рис. 2.3. Рассматривая САПР как организационно-техническую систему, необходимо к вышеперечисленным уровням проектирования добавить еще
один – организационно-управленческие работы. На этом уровне
нисходящего проектирования в рамках текущей и прогнозной координационно-управляющей и организационно-методической деятельности выпускаются приказы, утверждаются планы-графики,
калькуляции, заключаются договоры и т. д. Каждый документ
оформляется по утвержденной форме.
Организационно-управленческие работы
Системное проектирование
Схемотехническое
проектирование
Проектирование
программмного обеспечения
Конструкторское
проектирование
Технологическая подготовка
производства и контроля
Комплексная отработка
(отладка)
Рис. 2.3. Схема концептуальной модели процесса проектирования БЦВМ
28
Формулировка ТЗ
Уровень
структурного
проектироС
вания
ПМ
Р А О Д
Декомпозиция и оформление частных ТЗ
Уровень
функционального
проектирования
ЧТЗ
С
ПМ
ЧТЗ
Р А О Д
С
ПМ
Р А О Д
ЧТЗ
Декомпозиция и оформление частных ТЗ
Уровень
ЧТЗ
схемотехнического
С ПМ
проектирования
ЧТЗ
Р А О Д
С
ПМ
Р А О Д
ЧТЗ
Декомпозиция и оформление частных ТЗ
К уровню конструкторского проектирования
Рис. 2.4. Уровни начальных этапов процесса проектирования
Анализ организационно-управленческих работ будет рассмотрен на примере обследования эксплуатационно-дистрибьюторского предприятия (см. 2.2), поскольку «вес» таких работ на предприятии является наибольшим.
На начальном уровне проектирования (рис 2.4) решаются типовые задачи синтеза (С), построения модели (ПМ), расчета (Р ), анализа (А), оценки (О) и выпуска документации (Д) для каждой составной части сложного изделия (объекта проектирования). В процессе проектирования сверху вниз изделие высшего уровня сложности разбивается (декомпозируется) на составные части (узлы,
устройства, компоненты). При этом для каждой составной части
изделия, которую требуется спроектировать, формируется частное
техническое задание (ЧТЗ).
Схема, изображенная на рис. 2.5, позволяет установить взаимосвязь типовых проектных задач. Вложенность задач одна в другую свидетельствует о рекурсивном выполнении одних и тех же
процедур на каждом уровне. При синтезе создаются, а при анализе
оцениваются проектные решения.
29
Формулировка ТЗ
Уровень К
Корректировка ТЗ
СИНТЕЗ
Синтез структуры
Выбор или построение
модели
Изменение структуры
Выбор или расчет исходных
значений параметров
ПАРАМЕТРИЧЕСКИЙ
СИНТЕЗ
Модификации
параметров
Анализ многовариантный
Анализ одновариантный
Получено требуемое проектное
решение?
Нет
Выбор способа улучшения
проекта
Да
Оформление
документации
Уровень К+1
Формулировка ТЗ
Рис. 2.5. Взаимосвязь типовых проектных процедур
Процедуры анализа делятся на процедуры одно- и многовариантного анализа. При одновариантном анализе для заданных внутренних и внешних параметров определяются значения выходных
параметров объекта. В частности, при моделировании, подобная
задача обычно сводится к однократному решению уравнений, составляющих математическую модель. Многовариантный анализ
заключается в исследовании свойств объекта в некоторой области
пространства внутренних параметров, что требует при моделировании многократного решения уравнений (многократного выполнения одновариантного анализа).
Процедуры синтеза делятся на процедуры структурного и параметрического синтеза. Целью структурного синтеза является
определение структуры объекта – перечня его составных частей и
способа связи этих частей между собой. Параметрический синтез
30
заключается в определении числовых значений параметров объекта (составных частей) при заданных структуре и условиях его работоспособности, т. е. требуется найти точку или область в пространстве внутренних параметров, в которых выполняются те или иные
условия (обычно условия работоспособности).
Состав работ и проектных процедур по всем уровням и этапам
проектирования приведен в табл. 2.1–2.7, где обозначения этапов
проектирования аналогичны приведенным на рис. 1.4.
Для каждого уровня проектирования объекта (см. рис. 2.4) может быть построена матрица (табл. 2.8), столбцы которой определяются количеством и составом проектных процедур, а строки соответствуют характеристикам проектных процедур.
По признаку автоматизации проектные процедуры подразделяются на выполняемые вручную (код 0), путем автоматизии (код 1),
полностью автоматизированно (код 2).
Таблица 2.1
Состав организационно-управленческих работ
№
п/п
Наименование работ
1 Разработка приказа об открытии темы (заказа)
Подготовка материалов по составлению и оформле2
нию договоров
Разработка калькуляции, ориентировочной смет3 ной стоимости работ по договору и их согласование
с Заказчиком
Выпуск приказов и указаний об организации работ
4
по теме (заказу)
Составление, согласование и утверждение план5
графиков работ по теме (заказу)
Разработка и согласование протокола взаимодей6
ствия
Заключение договоров на разработку и поставку
7 комплектующих изделий систем и эдектрорадиоэлементов (ЭРЭ)
8 Заключение договоров с контрагентами
Разработка и согласование протоколов номенкла9
туры конструкторской документации (КД)
Оформление актов на закрытие этапов работы по
10
теме (технических и финансовых)
Этапы разработки
ПТ ЭП ТП РП
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
31
Таблица 2.2
Состав проектных процедур на начальном уровне проектирования
№
п/п
Проектные процедуры
1 Анализ исходных данных заказа
2 Анализ технической литературы и прототипов
3 Патентный поиск и подбор патентных материалов
Разработка и согласование проекта технического
4
задания (ТЗ)
5 Выбор и обоснование структурной схемы
6 Разработка схемы деления
Математическое описание задач, выбор численных
7
методов решения задач
8 Разработка алгоритмов работы систем и устройств
Определение требований к техническим средствам
9
систем и устройств
Этапы разработки
ПТ ЭП ТП РП
+
+
+
+
+
+
+
+
+
+
+
Таблица 2.3
Состав проектных процедур
на уровне схемотехнического проектирования
№
п/п
Проектные процедуры
1 Разработка и согласование системы связей
2 Составление перечня ЭРЭ изделия
Составление тематических карточек на разработку
3
новых ЭРЭ
Разработка принципиальных электрических схем
4 и перечней элементов (макетирование, моделирование составных частей изделия)
5 Разработка карт рабочих режимов
Разработка алгоритмов микропрограмм микропро6
цессорных устройств (МПУ)
Разработка структур микрокоманд и разработка
7
микропрограмм МПУ
8 Разработка схем электрических соединений
9 Разработка схем электрических подключений
Разработка частных технических заданий на про10 ектирование конструктивно-функциональных модулей (КФМ)
32
Этапы разработки
ПТ ЭП ТП РП
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Таблица 2.4
Состав проектных процедур на уровне конструкторского проектирования
№
п/п
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
Проектные процедуры
Составление спецификаций
Составление ведомости спецификаций (ВС)
Составление ведомости ссылочных документов
Расчет драгоценных металлов
Расчет цветных металлов
Расчет показателей уровня стандартизации и унификации
Составление паспорта
Составление ведомости упаковки
Составление инструкции по упаковке
Разработка этикетки
Составление ведомости держателей подлинников
Составление пояснительной записки
Составление ведомости ЗИП
Составление инструкции по использованию ЗИП
Составление формуляра
Составление описи
Составление карт технического уровня и качества
Расчет нормы расхода запасных частей на 100 ч эксплуатации
Расчет нормы расхода материалов на 100 ч эксплуатации
Разработка сборочных чертежей
Разработка габаритных чертежей (ГЧ)
Разработка чертежей деталей (слоев)
Разработка чертежей общего вида
Разработка электромонтажных чертежей
Разработка монтажных чертежей
Разработка упаковочных чертежей
Составление ведомости документов на носителях
данных
Составление данных контроля
Составление данных сверления
Составление данных фотошаблонов
Составление таблиц проверки монтажа электрических схем
Теплофизические расчеты
Расчеты систем охлаждения
Расчеты показателей надежности и радиационной
стойкости
Этапы разработки
ПТ ЭП ТП РП
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
33
Таблица 2.5
Состав проектных процедур на уровне проектирования
программного обеспечения устройств и систем
№
п/п
Проектные процедуры
Этапы разработки
ПТ
ЭП
ТП РП
1 Разработка ТЗ на программирование
2 Разработка карт распределения памяти МПУ
3 Разработка таблиц данных (рабочих программ)
Составление данных программ (на машинных носи4
телях)
5 Составление спецификаций
Разработка сборочных чертежей программного обе6
спечения
Разработка комплекта документации по программ7
ному обеспечению
8 Разработка методики испытаний программ
+
+
+
+
+
+
+
+
Таблица 2.6
Состав проектных процедур на уровне технологической подготовки
производства и контроля
№
п/п
Проектные процедуры
1 Отработка, анализ изделий на технологичность
Проектирование перспективных технологических
2
процессов
Проектирование элементов производственных си3
стем
Разработка технологической планировки производ4
ственных подразделений
5 Определение спецификации рабочих мест
6 Проектирование технологических процессов
Разработка управляющих программ для оборудова7
ния с ЧПУ
8 Разработка оснастки и инструмента
9 Разработка средств контроля
34
Этапы разработки
ПТ
ЭП
+
ТП РП
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Таблица 2.7
Состав проектных процедур на уровне комплексной отработки (отладки)
№
п/п
1
2
3
4
5
6
7
8
9
10
11
12
13
Проектные процедуры
Составление руководств по технической эксплуатации (РЭ)
Составление регламента технического обслуживания (РО)
Составление инструкций по проверке, настройке и
регулировке (И1)
Составление программ и методик испытаний (ПМ)
Составление инструкций по стыковке (ИЗ)
Составление инструкций по проверке (И4)
Составление руководства по использованию эксплуатационных документов (Д7)
Составление инструкций по эксплуатации (ИЗ)
Составление инструкции по техническому обслуживанию (ИО)
Разработка технических условий (ТУ)
Проверка работоспособности изделия
Проверка изделия на соответствие ТУ
Анализ результатов испытаний, составление протокола по результатам испытаний
Этапы разработки
ПТ ЭП ТП РП
+
+
+
+
+
+
+
+
+
+
+
+
+
Таблица 2.8
Характеристики проектных процедур
на K-м уровне проектирования объекта
Код
Код
Признак
ТрудоКоличество Стоимость
проектной
средства
автоматизации емкость
листов
выполнения
процедуры автоматизации
(0, 1, 2)
проектной документа процедуры,
процедуры, в формате А4 тыс. руб.
чел.-ч
Приведенное в табл. 2.8 (после её заполнения) матричное представление проектных процедур дает возможность наряду с использованием хорошо разработанного аппарата матричных преобразований при формировании матриц смежности и матриц инциденций естественно перейти к методам сетевого анализа на графовых
35
ориентированных и неориентированных структурах. Это дает возможность применить качественно новый аналитический аппарат,
позволяющий количественно оценить, оптимизировать и исследовать технические и (или) технологические параметры проектных
процедур с целью их автоматизации соответствующими инструментами (подсистемами) САПР [1].
2.2. Обследование эксплуатационно-дистрибьюторского
предприятия
Поскольку подходы к автоматизации проектирования и производства, рассмотренные выше, представляют только часть единой
системы ЖЦИ, то далее излагается обследование эксплуатационно-дистрибьюторского предприятия.
Рассмотрим обследование автотранспортного предприятия1, деятельность которого заключается в техническом обслуживании,
сопровождении и ремонте автомобильной техники; организации
наиболее эффективной эксплуатации техники; мониторинге технологий её использования и принципов управления бизнесом; обратных связях на проектно-производственные предприятия; обучении
персонала эксплуатации и обслуживанию техники.
Цели и задачи обследования:
определить и в явном виде представить процедуры и операции,
осуществляемые сотрудниками предприятия по обработке, анализу и управлению материальными, финансовыми и информационными потоками;
определить из всего множества процедур и операций те из них,
которые подлежат автоматизации;
разработать рекомендации по созданию автоматизированных
систем управления планированием и дистрибьюцией автотранспортной техники (в дальнейшем АСУП);
осуществлять обратные связи на процесс проектирования и производства, в том числе интеграцию АСУП и САПР;
В процессе обследования осуществляется анализ возможностей
автоматизации на предприятии. Результаты этого анализа являют-
1 В работах по обследованию предприятия принимали участие доценты ГУАП
кандидаты технических наук В. А. Галанина, С. Л. Козенко и начальник учебной
лаборатории И. К. Гришина.
36
ся базой для создания АСУП предприятия, которая предназначена
для решения следующих задач:
оперативно принимать решения руководству предприятия на
основе инструментов АСУП;
управлять ресурсами предприятия, в том числе при наличии
удаленных филиалов;
проводить анализ бизнес-ситуации;
проводить анализ распределения прямых и накладных расходов;
проводить стратегическое и тактическое прогнозирование и
планирование;
осуществлять мониторинг состояния делопроизводства;
управлять техническим обслуживанием оборудования.
На предприятиях эксплуатационно-дистрибьюторского типа,
объем организационно-управленческих решений при движении
материальных, финансовых и информационных потоков весьма
велик и разнообразен. При этом многие параметры оказываются настолько взаимосвязанными, что руководить предприятием
и принимать решения на всех уровнях от генерального директора
до исполнителя, основываясь только на интуиции, становится невозможным. Информационные технологии позволяют принимать
решения обоснованно за счет алгоритмизации и компьютерной обработки огромных потоков информации.
Процесс обследования в этом случае так же, как и в проектнопроизводственном предприятии начинается с формирования рабочей группы.
В состав рабочей группы входят представители Заказчика и Исполнителя. Из числа представителей Заказчика в обязательном
порядке назначается руководитель группы и его помощники по
направлениям. Руководитель решает вопросы, связанные с обоснованностью и полномочиями согласованных действий представителей Заказчика и Исполнителя, обеспечивает их доступ к информации и средствам офисной техники. Целесообразно оформить состав
и полномочия рабочей группы письменным (или устным) приказом
по предприятию.
При обследовании рабочая группа собирает следующую информацию:
по выпускаемой продукции, услугам и их частям;
по организационной структуре предприятия и отдельных подразделений;
по перечню всех управленческих, организационных, производственных процедур;
37
по техническим средствам сбора, хранения и обработки информационных потоков;
по кадровому и квалификационному составу предприятия.
При проведении обследования проводится изучение документов, анкетирование и устный опрос.
Деятельность рабочей группы осуществляется в следующей последовательности:
1) подготовка, согласование, оформление и подписание Договора и соответствующих документов на проведение работ на предприятии;
2) разработка, согласование и утверждение календарного плана
работ по обследованию предприятия;
3) проведение обследования, сбор информации;
4) анализ результатов обследования;
5) подготовка научно-технического отчета;
6) представление результатов обследования Заказчику.
При составлении плана обследования следует учесть следующие
мероприятия.
1. Собеседование с руководством предприятия и руководителями подразделений предприятия с целью получения ответов на следующие вопросы:
какие оперативные решения необходимо принимать на данном
уровне управления;
какой информации не хватает для принятия оперативных решений;
какова схема формирования и прохождения управленческих решений;
каковы формы и виды оформления управленческих решений;
сформулировать (если это возможно) задачи по желательной реорганизации структуры предприятия (подразделения).
2. Сбор действующих форм нормативных и распорядительных
документов.
При сборе действующих форм следует учесть:
являются ли эти формы стандартными и используемыми для
внешней отчетности или их можно изменять в соответствии с задачей автоматизированной обработки;
есть ли дублирование на различных рабочих местах;
существуют ли недокументируемые (устные) распоряжения, которые предполагается автоматизировать.
3. Распределение опросных листов (анкет обследования). При
распределении опросных листов целесообразно:
38
разработать предварительные (типовые) опросные листы, включающие опросные вопросы;
раздать эти опросные листы руководителям соответствующих
подразделений и на рабочие места;
собрать опросные листы и проанализировать ответы на вопросы,
предложенные в них;
по результатам анализа произвести корректировку соответствующих форм и провести повторное обследование.
По результатам опроса заполняются следующие таблицы:
Состав входной информации по предприятию;
Состав входной информации по подразделению;
Состав входной информации по рабочему месту;
Состав выходной информации по предприятию;
Состав выходной информации по подразделению;
Состав выходной информации по рабочему месту.
Заполняются также таблицы компьютерной оснащенности руководителя подразделения и рабочих мест, в том числе:
Состав технических средств;
Состав системного программного обеспечения;
Состав прикладного программного обеспечения.
Общие принципы процессов на рассматриваемом предприятии
можно представить в виде описания процессов его работы “как
есть” и “как будет” (табл. 2.9, 2.10).
Таблица 2.9
Описание текущих процессов работы предприятия (“как есть”)
Наименование
процессов
Обслуживание
заказчиков
Закупка изделий
иностранными
заказчиками
Описание процессов
Входные потоки:
Заказы от клиентов
Готовая продукция от поставщиков
Материалы и запасные части от поставщиков
Выходные потоки:
Заказы на проектирование и изготовление изделий
поставщику
Готовое изделие клиенту
Заказы поставщику на запчасти
Входные потоки:
Заказы на проектирование и изготовление изделий
Выходные потоки:
Готовая продукция
39
Продолжение табл. 2.9
Наименование
процессов
Описание процессов
Закупка продукции Входные потоки:
местными клиентами Готовая продукция от поставщика
Выходные потоки:
Заказы на изготовление изделий поставщику
Поставка материалов Входные потоки:
и запасных частей
Заказы на материалы и запасные части
Выходные потоки:
Материалы и запасные части от поставщиков
Процессы
Входные потоки:
в коммерческом
Контракты на закупку изделий, материалов и запотделе
частей от поставщиков
Стоимости производства
Выходные потоки:
Прайс-листы, счета, счета-фактуры
Прайс-листы, поступающие в отдел экспортных
продаж
Процессы связей
Входные потоки:
с проектированием и План проектирования и производства изделий от
производством
поставщиков
Выходные потоки:
Готовая продукция, направляемая дистрибьюторам
Затраты на проектирование и изготовление изделий
Информация об отгруженной продукции
Заказы на изделия и запасные части поставщикам
Процессы
Входные потоки:
планирования
Планы на проектирование и производство изделий
и планы продаж дистрибьюторов
Выходные потоки:
Подтверждение приема заказа поставщикам на
оговоренный срок, направляемое дистрибьюторам
Планы поставщика производства изделий, направляемые в производство и отгрузку
Процессы отдела
Входные потоки:
продаж
Прайс-листы, от коммерческого отдела
Недельный список счетов от бухгалтерии
Выходные потоки:
Прайс-листы и маркетинговые данные
Формирование прайс- Входные потоки:
листов
Затраты на проектирования и производство от поставщика
40
Окончание табл. 2.9
Наименование
процессов
Ведение контрактов
Разработка новых
изделий
Обучение и переподготовка
Описание процессов
Затраты на эксплуатацию от дистрибьюторов
Данные бухгалтерии
Прайс-листы поставщиков
Выходные потоки:
Прайс-листы для отдела продаж
Прайс-листы в коммерческий отдел
Входные потоки:
Договора на поставку изделий, комплектующих и
материалов от поставщиков
Договора по контрактам от клиентов
Выходные потоки:
Договора на изделия и запчасти
Входные потоки:
Заявки и предложения на новые изделия
Выходные потоки:
Проекты новых изделий направляются поставщику
Входные потоки:
Учебные планы, программы, методические разработки
Выходные потоки:
Повышение квалификации работников
Обучение, тренинг
Таблица 2.10
Описание процессов работы предприятия (“как будет”)
№ Наименование процессов Очеп/п и соответствующих БД редь
1 Ведение системных
справочников
1
Описание функции
Системные справочники предназначены
для ведения информации, на которую
существуют ссылки в программном коде
информационной системы (ИС). Системные справочники создаются Разработчиком и заполняются Разработчиком
совместно с Администратором приложения в процессе первоначальной настройки
системы или после ее модификации.
В дальнейшем Системные справочники
поддерживаются в актуальном состоянии
Администратором приложения. Отдель41
Продолжение табл. 2.10
№ Наименование процессов Очеп/п и соответствующих БД редь
Описание функции
ные Системные справочники могут заполняться и корректироваться отдельными
Пользователями в соответствии с их правами доступа
2 Ведение справочника
регионов
1
Справочник Регионы предназначен для
ведения иерархического списка стран,
регионов, районов, местностей, городов,
поселков и т. д. Содержит информацию о
типе региона. Заполняется и поддерживается в актуальном состоянии Администратором приложения совместно со специалистом по маркетингу.
Входные потоки:
Географические карты и справочники
Информация из существующих программ
3 Ведение структуры
предприятия
1
Справочник Предприятия предназначен
для ведения иерархического списка
подразделений и филиалов, входящих
в состав предприятия, с учетом их подчиненности. Заполняется и поддерживается в актуальном состоянии Администратором приложения. При необходимости могут быть предусмотрены сервисные процедуры для корректного переноса финансовой и экономической информации в случае изменения структуры
предприятия.
Входные потоки:
Юридические документы об изменениях
статуса предприятия
4 Ведение структуры
подразделений предприятия
1
Иерархический Справочник Подразделения предназначен для ведения иерархической структуры подразделений предприятия с учетом их подчиненности. Заполняется и поддерживается в актуальном состоянии Администратором приложения.
Входные потоки:
Документы о структуре предприятия
42
Продолжение табл. 2.10
№ Наименование процессов Очеп/п и соответствующих БД редь
Описание функции
5 Ведение базы данных
сотрудников
1
Справочник Сотрудники предназначен
для ведения списка сотрудников с учетом
их принадлежности к подразделениям.
Содержит информацию о должности сотрудника, список документов об образовании, тренинге и повышении квалификации сотрудника, список закрепленных
за сотрудником регионов (для продавцов,
монтажников и пр.). Заполняется и корректируется
Входные потоки:
Личные дела сотрудников – из Отдела кадров
Тренинг – из Технического отдела
Распределение по филиалам
6 Ведение базы данных
юридических лиц
1
Справочник Юридические лица предназначен для ведения списка предприятий,
являющихся юридическими лицами, их
банковских реквизитов и списка сотрудников этих предприятий (контактных
лиц). Содержит информацию о типе предприятия (поставщик, заказчик, потенциальный заказчик), его регионе и др.
Заполняется непосредственно в форме
Справочника, а также при вводе договоров и заказов соответствующими Пользователями. Список банковских реквизитов заполняется Бухгалтером, а также
при вводе договоров и заказов, при
регистрации и выписке счетов соответствующими Пользователями
Входные потоки:
Договоры, заказы, входящие счета
Маркетинговая информация
7 Ведение справочника
банков
1
Справочник Банки предназначен для ведения списка банков. Заполняется непосредственно в форме Справочника Бухгалтером, а также при вводе договоров и
заказов, при регистрации и выписке счетов соответствующими Пользователями.
43
Продолжение табл. 2.10
№ Наименование процессов Очеп/п и соответствующих БД редь
Описание функции
Входные потоки:
Договоры, заказы, входящие счета, информация своих банков
8 Ведение базы
данных объектов
(мест реальных и
потенциальных
заказов)
1
Справочник Объекты предназначен для
ведения списка предприятий, в которых
установлены или могут быть установлены
изделия предприятия или аналогичные
изделия других фирм (конкурентов). Содержит регион объекта, его адрес, сведения о наличии лицензии на эксплуатацию изделий. Заполняется Продавцами
непосредственно в форме Справочника, а
также при вводе договоров и заказов.
Входные потоки:
Договоры, заказы, информация продавцов
9 Ведение предложений
по заказам
1
Модуль Предложения предназначен для
быстрого ввода Продавцами предложений
по заказам, т. е. Заказов со статусом
“Предложение”
10 Расчет стоимости заказа
1
Процедура Расчет стоимости заказа предназначена для автоматического расчета
приблизительной или точной цены заказа
в зависимости от выбранного прайслиста. При расчете используется Спецификация заказа и список Тарифов на
изделия и услуги выбранного прайслиста. Процедура используется модулями
Предложения, Предварительные заказы,
Заказы, Заказы на материалы, Расчет
комиссионных и др.
11 Ведение презентаций
1
Модуль Презентации предназначен для
работы Продавцов с Презентациями. Продавец имеет возможность просматривать
список презентаций, корректировать существующие и вводить новые записи. По
каждой презентации Продавец может вести список объектов и мест установки изделий
44
Продолжение табл. 2.10
№ Наименование процессов Очеп/п и соответствующих БД редь
Описание функции
12 Запись предварительных заказов
1
Модуль Предварительные заказы предназначен для быстрого ввода Продавцами
предварительных заказов, т. е. Заказов со
статусом “Предварительный заказ”
13 Ведение договоров по
проектам
1
Модуль Договоры предназначен для
работы Продавцов с договорами по проектам. Пользователь имеет возможность
просматривать и корректировать список
Договоров, доступных ему в соответствии
с его правами доступа, и вводить новые
записи. Пользователь имеет возможность
просматривать и корректировать список
объектов Договора, а также список документов по договору.
Модуль Договоры также используется для
ведения договоров на закупку запчастей и
материалов соответствующими Пользователями в коммерческом и других отделах
14 Ведение заказов
1
Модуль Заказы предназначен для работы Продавцов и Разбработчиков заказов
с Заказами. Пользователь имеет возможность просматривать список своих или
всех заказов, корректировать существующие и вводить новые записи. По
каждому заказу Пользователь имеет
возможность просматривать и корректировать список объектов заказа, а по
каждому объекту – список мест установки изделий. По каждому изделию
заказа Пользователь имеет возможность
просматривать и корректировать список составных частей изделия и их
атрибутов. При вводе нового заказа и
выборе типа изделия список составных
частей изделия автоматически копируется из справочника типовых изделий.
Для каждой составной части изделия
Пользователь может ввести размеры и
другие атрибуты. Далее Пользователь
может выбрать тип прайс-листа (или
45
Окончание табл. 2.10
№ Наименование процессов Очеп/п и соответствующих БД редь
Описание функции
использовать подключенный по умолчанию) и рассчитать цену изделия или
всего заказа
15 Запись характеристик
изделия
1
Функция Запись характеристик изделия
предназначена для работы Продавцов
и Разработчиков заказов с Заказами.
Пользователь имеет возможность просматривать и корректировать список
значений атрибутов заказа, в том числе
размеров изделий. После ввода характеристик Пользователь имеет возможность
выполнить генерацию размеров деталей
для передачи в программу оптимизации
(«производственные размеры»)
Входные и выходные потоки, представленные в табл. 2.9, состоят из соответствующих процедур и операций. Например, договор
на поставку запчастей представляет собой процедуру, включающую операции «составляющие спецификаций», «финансовые обязательства», «календарные оценки».
Рассмотрим результаты обследования предприятия «как есть»,
начиная со структуры предприятия.
На основании анализа опросных листов структура предприятия
может быть представлена в виде структурно-функциональной схемы (рис. 2.7).
Деятельность предприятия осуществляется в двух направлениях.
1. Основной вид деятельности.
В рамках комплексного решения проблем муниципального
транспорта:
поставка и эксплуатация муниципального пассажирского электро- и автотранспорта;
поставка и эксплуатация специальной коммунальной и дорожно-строительной техники;
поставка запчастей;
производственная деятельность.
2. Дополнительный вид деятельности:
проведение маркетинговых исследований, в том числе по связям
с проектированием и производством;
46
обучающая деятельность;
проведение семинаров по различным аспектам автобизнеса;
издание газеты.
Процесс функционирования рассматриваемого предприятия,
как и проектно-производственного (см. 2.1), адекватно отражается в документах-носителях информации о процедурах, решениях
и контрольно-управляющих воздействиях на эти процессы. Виды
деятельности как на предприятии в целом, так и в отдельных его
подразделениях, представлены на рис. 2.6–2.11. Однако, в отличие
от рассмотренных в п. 2.1 процессов, здесь основной акцент делается на управленческие процедуры и решения.
По результатам анализа входных и выходных документов разрабатываются схемы взаимодействия подразделений предприятия
с внешними организациями.
На основе анализа схем и материалов обследования рабочих
мест разрабатываются схемы документооборота прохождения Заказов на поставку техники и запчастей по предприятию, выявляется состав и характеристики имеющихся средств автоматизации на
предприятии.
В качестве иллюстрации приведем фрагмент результатов обследования и анализа предприятия “как есть”.
По схемам прохождения Заказов:
1) отсутствие автоматизации процесса информационного сопровождения прохождения Заказов в “Центре продаж” (“Журнал
учета контактов” заполняется и обрабатывается вручную) приводит к нарушению оперативности выполнения плана-графика контактов с потенциальными покупателями и к потере значительной
части клиентов;
2) существенная часть времени тратится на согласование документов, сопровождающих договор (юрист, бухгалтерия, руководство);
3) отсутствие автоматизированной базы учета процессов проектирования и производства автотранспорта и прямых связей с САПР
приводит к значительным затратам времени по определению их
“перспективности” и надежности;
4) сложность алгоритмов работы с предприятиями – должниками и предприятиями – контрагентами (при составлении цепочек
взаимозачетов) требует выделения этого направления работ в самостоятельную задачу с целью дальнейшей автоматизации;
5) отсутствие должной автоматизации (слабая вычислительная
база, отсутствие прямого доступа к Интернет, нормативным базам
“Консультант”) в “Коммерческом центре” приводит к недостаточ47
Секретарь
Референт
Центр маркетинговой
информации
и инновационных проектов
Коммерческий
центр
Руководитель
(президент)
Отдел поставок
электротранспорта
КЦ
Автобаза
Аналитический
отдел
Отдел поставок
автотехники
Отдел продажи
автотехники
Отдел продажи
спецтехники
Юридический
отдел
Отдел кадров
Рекламномаркетинговый
отдел
ЦМИИП
Рис. 2.6. Виды деятельности предприятия
Редакция газеты
“Омнибус”
•Поиск разработчиков автотехники и
электротранспорта
•Получение и отправка техники Заказчику
•Аналитический обзор рынка
Общий отдел
Бухгалтерия
• Финансовая
деятельность
предприятия
Центр продаж
Работа с Заказчиками
•Продажа автотехники и запчастей
•Организация семинаров среди
Заказчиков
•Составление внутренних прайслистов
•Реклама продукции
Отдел руководства
филиалами
Работа с проектно-производственными
предприятиями
П.1
ЦП
•Реклама предприятия
•Представление предприятия в сети ИНТЕРНЕТ
•Организация участия в выставках
•Проведение маркетинговых исследований и
выработка рекомендаций
•Подготовка и проведение рекламно-имиджевых
акций
Б
48
Отдел рекламы
Отдел продажи
запчастей
49
Руководитель
юридической
службы
кадров
Начальник
отдела
Секретарь
Референт
ЦМИ.3
Менеджер
по рекламе
газеты
Редактор
ЦМИ.1
ЦМИ.4
ЦМИ.2
Менеджер
(ИНТЕРНЕТ)
•
Менеджер
Начальник
общего
отдела
Рис. 2.7. Виды деятельности подразделения «Центра маркетинговой информации»
Системный
администратор
Начальник
рекламномаркетингового
отдела
ЦМИ.7
Руководитель
(директор)
ЦМИ.5
Начальник
Автобазы 1
КЦ.2
КЦ.3
Менеджер 1
Менеджер
Зам. директора КЦ
по электротранспорту
Менеджер №1
Зам. директора КЦ
по поставкам
автотехники
КЦ.5
Рис. 2.8. Виды деятельности подразделения «Коммерческий центр»
Начальник
Автобазы №1
Зам. директора КЦ,
управляющий
автобазой
Руководитель
(директор)
КЦ.1
КЦ.4
50
Начальник
аналитического
отдела
51
АБ.2.1.1
Автослесари, механики
КЦ.2
Внутренняя
развозка
Внешняя
развозка
Водители
Зам.
управляющего
автобазой
по технике
АБ.2.2
Секретарь
(диспетчер)
Охрана
Рис. 2.9. Виды деятельности подразделения «Коммерческий центр автобазы»
Нач. отдела
гарантийного
обслуживания
Ремонтная зона
Первый зам.
управляющего
автобазой
АБ.2.1
Управляющий
автобазой
АБ.2.2.1
52
Менеджер 1
Начальник
отдела
продажи
автотехники
Менеджер N
Представитель (Курган)
Начальник
отдела
продажи
запчастей
ЦП.1
...
...
Представитель (Минск)
Начальник
отдела
руководства
филиалами
Представитель (Москва)
ЦП.5
ЦП.4
ЦП.3
Рис. 2.10. Виды деятельности подразделения «Центр продаж»
...
Начальник
отдела
продажи
спецтехники
Руководитель
ЦП.6
ЦП.2
Начальник
отдела
рекламы
Кассир
Б.4
Зам.
главного
бухгалтера
Б.2
Б.1
Б.3
Бухгалтер
Руководитель
(гл. бухгалтер)
Рис. 2.11. Виды деятельности подразделения «Бухгалтерия»
ной эффективности проводимых в подразделении работ, в частности по взаимозачетам;
6) отсутствие автоматизации планирования и оперативной связи с автобазой приводит к неритмичной работе автобазы (недостаточно оперативное оповещение о прибытии техники, о сроках ее
реализации и т. д.);
7) отсутствие автоматизированного учета наличия техники на
стоянке, ее состояния, графика движения приводит к потере оперативности в общении с клиентами;
8) сложность и многоплановость принятия решений руководителем предприятия требует разработки алгоритма и соответствующего пакета программ “Принятие решений ЛПР”.
Рекомендации по организации АСУП предприятия “как будет”
также можно проиллюстрировать по результатам обследования
предприятия.
Анализ результатов обследования показал, что применительно к предприятию рекомендуется структура АСУП с центральной
базой данных (БД). В будущей центральной базе данных (ЦБД)
АСУП следует сконцентрировать абсолютное большинство процедур по однообразным, систематически повторяющимся операциям, выполняемым сотрудниками предприятия. Основным этапом
функционирования АСУП является сбор, регистрация и ввод первичных данных. Необходима разработка общих для всех отделов
норм и правил регистрации и ввода первичной информации. Обеспечение достоверности первичных данных достигается за счет “обратных связей” от лица принимающего решения (ЛПР) и внешних
53
источников, а также контроля и коррекции вводимой информации. Формирование достоверных БД по “поставщикам”, “заказчикам”, “технике” и т. д. полностью определяется надежностью
первичных данных.
В качестве примера на рис. 2.13 показана связь таблиц в БД «Заказчики»: “Заказчики автотехники”, “Заказчики электротранспорта”, “Заказчики спецтехники” и “Заказчики запчастей”. Также
на рис. 2.12 введены сокращения ранее рассмотренных названий
компонентов структуры предприятия (см. рис. 2.6): ЦМИИП –
центр маркетинговой информации и инновационных проектов,
ЦП – центр продаж, КЦ – коммерческий центр, АБ – автобаза.
Приведем краткий алгоритм работы с БД “Заказчики” (на примере обработки заказа на поставку автотехники).
1. При поступлении заказа на поставку автотехники информация о Заказчике заносится в таблицу “Потенциальные Покупатели” (поля: “Вид Заказа”, “Дата первого контакта”, “Дата следующего контакта”).
2. При заключении сделки (оформлении Договора) данные о
Заказчике (только в случае “нового клиента”) заносятся в таблицу “Заказчики автотехники” (все поля) и в таблицу “Заказы” (все
поля, кроме поля “Дата оплаты”). В случае “старого клиента” данные заносятся только в таблицу “Заказы” (все поля, кроме поля
“Дата оплаты”).
3. Результат работы с клиентом заносится в таблицу “Потенциальные Покупатели” (поле “Результат”). Значение данного поля
используется для оценки перспективности Заказчика.
4. Поле “Дата оплаты” таблицы “Заказы” заполняется при оплате договора.
5. Таблица “Конфиденциальная информация” заполняется по
усмотрению руководства предприятия.
Аналогичным образом строятся базы “Поставщики”, “Техника”
и т. д.
В результате обследования эксплуатационно-дистрибьюторского предприятия рекомендованы для внедрения средства АСУП,
которые поддерживают полный набор управляющих функций
в рамках рассмотренного производственного процесса; планирование и контроль отклонений, регулирование и связь с САПР проектно-производственных предприятий. Сформулированы рекомендации по выбору СУБД и созданию локальной вычислительной сети.
Разработана структура и состав информационного обеспечения
рабочих мест.
54
КЦ.2
ЦМИ
ЦМИ.7
Б.1
Спецтехника
П
ЦП1
ЦП2
КЦ1
КЦ3
КЦ5
П
ЦП1
ЦП2
ЦП4
ЦП.2
Потенциальные
покупатели
ЦП.2
П
ЦП1
ЦП2
ЦП4
П
ЦП1
КЦ1
КЦ2
КЦ4
КЦ5
ЦМИ.1
ЦМИ.7
П
Б.1
П
ЦП1
ЦП4
КЦ1
КЦ2
ЦМИ.1
ЦМИ.7
Электротранспорт
П
ЦП1
КЦ1
КЦ4
КЦ5
Запчасти
Заказчики
Заказы
П
Б.1
ʿ
Президент П
Рис. 2.12. Структурная схема работы подразделений с базой данных «Заказчики»
П
ЦП1
ЦП2
КЦ1
КЦ3
КЦ5
АБ.2.1
АБ.2.1.1
АБ.2.2
ЦМИ.1
ЦМИ.7
Автотехника
П
ЦП1
ЦП2
КЦ1
КЦ3
КЦ5
АБ.2.1
АБ.2.1.1
АБ.2.2
ЦМИ.1
ЦМИ.7
ЦП.2
ЦМИ.1
П
ЦП1
ЦП2
КЦ1
КЦ3
КЦ5
ЦП
ЦП.2
КЦ.5
КЦ.4
КЦ.3
КЦ.1
АБ.2.2
АБ.2.1.1
АБ.2.1
АБ
ЦП.2
Бухгалтерия
КЦ
ЦП.2
Конфиденциальная
информация
55
Контрольные вопросы
1. Каковы цели и задачи обследования предприятия перед внедрением САПР?
2. Каков порядок обследования проектно-производственного
предприятия?
3. Чем отличается порядок обследования эксплуатационно-дистрибьюторского предприятия?
4. В чем сущность системного анализа при обследовании предприятия?
5. Каким образом осуществляется декомпозиция процессов проектирования и производства?
6. Как можно детализировать процедуры и операции на эксплуатационно-дистрибьюторском предприятии?
56
3. СТАНДАРТИЗАЦИЯ ПРИ ВНЕДРЕНИИ САПР
3.1. Стандарты в области проектирования и производства
Внедрение САПР осуществляется в пространстве стандартов,
которые в своем развитии обязательно включают средства САПР
[8]. В настоящее время глубокая кооперация, межотраслевые связи предприятий, а также необходимость гармонизации стандартов
с международными, обусловили необходимость создания комплексных систем межотраслевых стандартов. Эти системы объединяют
в каждом комплексе несколько десятков прогрессивных стандартов,
охватывающих все стадии ЖЦИ: исследование и проектирование,
подготовку производства, производство, эксплуатацию и ремонт.
Единая система конструкторской документации (ЕСКД) устанавливает для всех организаций страны единый порядок организации проектирования, единые правила выполнения и оформления
чертежей и ведения чертежного хозяйства, что упрощает проектно-конструкторские работы, способствует повышению качества
и уровня взаимозаменяемости изделий и облегчает чтение и понимание чертежей в разных организациях. ЕСКД дает возможность
применять компьютерные технологии для проектирования и обработки технической документации. В стандартах ЕСКД сохранена
преемственность с ранее действовавшими стандартами, а также
обеспечена согласованность правил оформления чертежей и схем
с рекомендациями ИСО и МЭК.
Комплекс стандартов ЕСКД разделяется на следующие группы:
0 – общие положения (ГОСТ 2.001 – ГОСТ 2.004);
1 – основные положения (ГОСТ 2.101 – ГОСТ 2.125);
2 – обозначение изделий и документов (ГОСТ 2.201);
3 – общие правила выполнения чертежей (ГОСТ 2.301 – ГОСТ 2.321);
4 – правила выполнения чертежей различных изделий (ГОСТ
2.401 – ГОСТ 2.428);
5 – правила учёта и обращения конструкторских документов
(ГОСТ 2.501 – ГОСТ 2.503);
6 – правила выполнения эксплуатационной и ремонтной документации (ГОСТ 2.601 – 2.608);
7 – правила выполнения схем (ГОСТ 2.701 – ГОСТ 2.711, ГОСТ
2.721 – ГОСТ 2.770, ГОСТ 2.780 – ГОСТ 2.782 – ГОСТ 2.797);
8 – выполнение макетной документации (ГОСТ 2.801 – ГОСТ
2.804, ГОСТ 2.850 – ГОСТ 2.857);
9 – прочие.
57
При проектировании изделий различают следующие стадии:
техническое предложение, эскизный проект, технический проект,
рабочая документация.
Техническое предложение представляет собой совокупность
конструкторских документов, обосновывающих целесообразность
разработки нового изделия, в том числе результаты маркетинга.
Эскизный проект – совокупность конструкторских документов,
содержащих принципиальные конструкторские решения, дающие
общее представление об устройстве и принципе работы изделия,
его параметры и габаритные размеры.
Технический проект – совокупность конструкторских документов, которые должны содержать окончательные технические решения и исходные данные для разработки рабочей документации.
Основные направления развития ЕСКД связаны с применением компьютерных технологий 2D и 3D моделирования с использованием программ Solid Works, T-Flex, AutoCAD и т. п. Широкое
применение находят системы автоматизации проектно-конструкторских работ на базе систем расчёта деталей машин Quick Calc и
приходящей ей на смену Win Machine. Применение при проектировании новых изделий информационных технологий, работа в интегрированной среде CAD-CAM, работа с трехмерными моделями
деталей и сборочных единиц позволяет использовать большой объем информации. Результатом этой работы является возможность
получения ассоциативных двухмерных чертежей, составления
технологии обработки деталей как на станках с ЧПУ, так и на простом оборудовании.
Единая система технологической документации (ЕСТД), как
и конструкторской, в значительной степени определяет трудоемкость, продолжительность подготовки производства и качество
продукции. ЕСТД представляет собой комплекс государственных
стандартов, устанавливающих взаимосвязанные правила разработки, оформления и обращения технологической документации.
Основное назначение стандартов ЕСТД заключается в установлении единых правил оформления и обращения технологических
документов в организациях и на предприятиях. Установленные
в стандартах ЕСТД правила и положения по разработке, оформлению и обращению документации распространяются на все виды
технологических документов.
Стандарты этой системы должны обеспечивать преемственность основных положений стандартов ЕСКД; они должны предусматривать возможность ее разработки, заполнения и обработки
58
средствами информационных технологий. Документация должна
базироваться на основе широкого применения типовых (групповых) технологических процессов (операций). Расширение области
применения типовых технологических процессов резко сокращает
объем работы технолога и объем разрабатываемой документации.
Внедрение стандартов ЕСТД играет существенную роль в выборе
единого технологического языка, применяемого промышленными
организациями и предприятиями, что позволяет повысить уровень
технологических разработок и заложить в технологические процессы высокие гарантии качества выпускаемой продукции и повышения производительности труда. Совместно с другими странами
проводится работа по созданию системы технологических документов с использованием компьютерных технологий, что способствует
расширению технических международных связей.
Весь комплекс стандартов ЕСТД разделяется на классификационные группы:
0 – общие положения (ГОСТ 3.1001);
1 – основополагающие стандарты (ГОСТ 3.1102 – ГОСТ3.1130);
2 – классификация и обозначение технологических документов
(ГОСТ 3.1201);
3 – учет применяемости деталей и сборных единиц в изделиях;
4 – основное производство, формы технологических документов и правила их оформления ГОСТ 3.1401 – ГОСТ3.1409, ГОСТ
3.1412 – ГОСТ 3.1428);
5 – основное производство, формы технологических документов
и правила их оформления на испытания и контроль (ГОСТ 3.1502–
3.1507);
6 – вспомогательное производство, формы технологических документов (ГОСТ3.1603);
7 – правила заполнения технологических документов (ГОСТ
3.1702 – ГОСТ 3.1707).
В условном обозначении стандарта после кода комплекса – цифра 3 с точкой стоит код производства, для которого разработан
стандарт, например 1 – для машиностроения и приборостроения.
Единая система программных документов (ЕСПД) устанавливает правила разработки, оформления и обращения программ и программной документации. Единые требования к разработке, сопровождению, изготовлению и эксплуатации программ и программной
документации обеспечивают: унификацию программных изделий
для взаимного обмена программами и применения ранее разработанных программ в новых разработках; снижение трудоемкости и
59
повышение эффективности разработки, сопровождения, изготовления и эксплуатации программных изделий; автоматизацию изготовления и хранения программной документации.
В состав ЕСПД входят следующие классификационные группы:
0 – общие положения;
1 – основополагающие стандарты;
2 – правила выполнения документации разработки;
3 – правила выполнения документации изготовления;
4 – правила выполнения документации сопровождения;
5 – правила выполнения эксплуатационной документации;
6 – правила обращения программной документации;
7,8 – резервные группы;
9 – прочие стандарты.
Внедрение САПР невозможно без учета перечисленных стандартов.
3.2. Стандарты обмена графической информацией
На предприятиях сферы проектирования и производства особое
место занимают методы обмена графической информацией [5]. Прикладные программы, например программы генерации сетки для
анализа по методу конечных элементов или траектории движения
деталей на линии станков с ЧПУ, требуют на входе технического
описания продукта. Данные технических требований делятся на
два типа. Первый тип данных – это данные чертежа; они включают векторное описание линий (сплошных, пунктирных, осевых,
размерных и выносных) и пояснительных данных комментариев,
символов и значений размеров), имеющихся на чертеже. Ко второму типу данных технических требований относится представление
твердотельной модели и некоторые пояснительные данные. Поэтому данные технических требований обычно импортируются из
CAD-системы – либо из системы автоматизированной разработки
чертежей, либо из системы твердотельного моделирования. Однако
все CAD-системы хранят результаты проектирования, т. е. данные
технических требований, в своих собственных структурах данных,
формат которых зависит от конкретной системы. Они могут не соответствовать входному формату используемой прикладной программы. Таким образом, когда две или более CAD/CAM/CAE-системы
объединяются и связываются в единое приложение для совместного использования данных, часто возникает проблема обмена дан60
ными. Фактически всегда имеется потребность связать воедино несколько систем либо внутри одной организации, либо внешне.
Различные CAD/CAM/CAE-системы хранят данные технических требований структурах разного вида, поэтому для переноса
данных необходимо преобразовать данные технических требований одной системы в формат другой системы.
Еще один конвертор необходим для переноса данных между двумя системами в противоположном направлении. Следовательно,
для каждой пары систем необходимо иметь два конвертора. Двунаправленные стрелки для каждой пары систем (рис. 3.1, а) предполагают наличие двух конверторов. Эти конверторы для каждой
конкретной пары систем называются прямыми конверторами
(direct translators). Если у нас есть п различных систем, нам необходимо разработать п(п – 1) конверторов, поскольку количество пар
систем равно п(п – 1)/2. Например, для обмена данными между 10
системами придется разработать 90 конверторов. Таким образом,
метод прямого конвертирования непрактичен, так как требует разработки слишком большого количества конверторов при необходимости работать со множеством систем. Более того, добавление
одной системы к п уже имеющимся потребует написания 2п дополнитеьных конверторов.
Однако обмен данными можно обеспечить, введя нейтральную структуру базы данных, называемую нейтральным файлом (neutral file), которая была бы независима от существующих
САПР. Эта структура будет действовать как промежуточная точка
коммуникации между различными структурами баз данных САПР
(рис. 3.1, б). Таким образом, в каждой системе будет своя пара кона)
б)
Система 1
Система N
Система 2
Система 1
Система 2
Система 6
446
Система 3
Нейтральный файл
Система 5
Система 5
Система 3
Система 4
Система 4
Рис. 3.1. Два метода обмена данными
между двумя различными системами
61
верторов для экспорта и импорта данных в этот нейтральный формат. Конвертор, преобразующий данные из собственного формата
данной системы в нейтральный формат, называется препроцессором {pre-processor), а конвертор, выполняющий обратное преобразование – постпроцессором (post-processor). Соответственно, в этом
случае для обмена данными между п системами потребуется 2п
конверторов, и лишь два дополнительных конвертора необходимо будет добавить при введении новой системы (рис. 3.2). Иными
словами, этот косвенный метод свободен от присущего прямому
методу недостатка, когда требовалось писать все возрастающее количество программ. Это основная причина, по которой косвенный
метод принят в качестве главного метода обмена данными между
различными системами, несмотря на то что в сравнении с прямым
методом у него имеются некоторые недостатки. В частности, прямые конверторы работают быстрее косвенных, и создаваемые ими
файлы данных обычно имеют меньший размер, чем нейтральные
файлы, генерируемые косвенными конверторами. Файл данных
в собственном формате конкретной системы обычно также оказывается меньше нейтрального файла из-за обобщенной природы
последнего. Когда мы переносим данные технических требований
через нейтральный файл, некоторая информация, как правило, теряется, особенно информация о топологическом дереве и ограничениях в системах параметрического моделирования.
Рассмотрим два типичных формата нейтрального файла: IGES
(Initial Graphics Exchange Specification – первоначальная специфи-
Специализированная
БД
Препроцессор
Нейтральный
файл
Специализированная
БД
Постпроцессор
Рис. 3.2. Обмен данными с использованием нейтрального файла
62
кация обмена графическими данными) и DXF (Drawing Interchange
Format – формат обмена чертежами). В настоящее время IGES является самым популярным форматом нейтрального файла, а формат
DXF используется главным образом для обмена данными чертежей.
Формат IGES. В 1979 году перед техническим комитетом, который состоял из компании Boeing, компании General Electric и Национального бюро стандартов США (National Buerau of Standards,
теперь Национальный институт стандартов и технологии), была
поставлена задача разработать метод обмена данными в рамках
программы интегрированного автоматизированного производства
(ICAM) для ВВС США. Результатом этих усилий явилось описание формата IGES версии 1.0, опубликованное в январе 1980 года.
В 1981 году оно было принято Американским Национальным институтом стандартов (ANSI) в качестве стандарта.
IGES был первым стандартным форматом обмена данными, разработанным для нужд передачи данных технических требований
между различными САПР. Ранние версии IGES были неявным
образом ориентированы на CAD/CAM-системы 1970-х и начала
1980-х годов, т. е. главным образом на обмен чертежами. В более
поздних версиях спектр типов данных, подлежащих обмену, был
расширен. Например, версия 2.0 поддерживала обмен данными
анализа по методу конечных элементов и данными печатных плат,
в версии 3.0 были расширены возможности пользовательских макрокоманд, играющих важную роль при обмене стандартными библиотеками деталей, в версии 4.0 была введена поддержка дерева
CSG, а в версии 5.0 появилась обработка данных структуры B-Rep.
IGES-файл состоит из шести разделов, которые должны идти
в следующем порядке: Flag (Флаг, необязательный раздел), Start
(Начало), Global (Глобальные данные), Directory Entry, или DE (Запись в каталоге), Parameter Data, или PD (Параметрические данные) и Terminate (Конец).
Раздел Flag используется только в сжатом ASCII-формате и бинарном формате. Данные в IGES-файле могут быть представлены
в двух форматах: ASCII и бинарном. Формат ASCII имеет две разновидности: фиксированную длину строки 80 символов и сжатую форму. Сжатая форма – это ASCII-файл, сжатый путем устранения пробелов между записями. Бинарный формат файла являет собой бинарное представление данных в виде потока битов в формате с фиксированной длиной записи. Чтобы идентифицировать формат файла
как сжатый ASCII, в столбец 73 раздела Flag записывается символ
С. Раздел Flag состоит из одной записи (строки) и предшествует раз63
делу Start. В бинарном формате первый байт (8 бит) раздела Flag содержит ASCII-символ В, служащий идентификатором типа файла.
В разделе Start дается описание файла в форме, воспринимаемой человеком. В нем указывается система, являющаяся источником данных, препроцессор и описываемый продукт.
Раздел Global содержит информацию о препроцессоре, а также
информацию, необходимую постпроцессору для интерпретации
файла. В частности, в этом разделе имеются следующие элементы:
символы, используемые в качестве разделителей между отдельными полями и записями;
имя самого IGES-файла;
количество значащих цифр в представлении целых чисел и чисел с плавающей точкой в системе-источнике;
дата и время создания файла;
масштаб пространства модели;
единицы измерения модели;
минимальная разрешающая способность и максимальные значения координат;
имя создателя файла и название организации.
При использовании препроцессоров и постпроцессоров с нейтральным форматом IGES на практике возникают следующие проблемы. Во-первых, внутренний способ представления элемента
в системе может отличаться от того, как этот элемент представляется в IGES. Например, дуга окружности в какой-то системе может быть определена через центр, радиус и начальный и конечный
углы, но в IGES она определяется через центр, начальную точку
и конечную точку. Таким образом, специализированный IGESконвертор должен выполнить преобразование с использованием
параметрического уравнения дуги. Такое преобразование должно выполняться дважды (при прямой и обратной конвертации), и
каждый раз значения параметров дуги искажаются из-за ошибок
усечения и округления. Вторая проблема более серьезна: она возникает, когда элемент не поддерживается явно, и поэтому его необходимо преобразовать в ближайший по форме доступный элемент.
Эта проблема часто имеет место при обмене данными между двумя
системами через IGES-файл, если конверторы этих систем поддерживают разные версии IGES. Типичный пример – потеря символьной информации в случае, когда одна из двух систем использует
более старую версию IGES, не поддерживающую макросы.
Формат DXF. Формат изначально разрабатывался для того,
чтобы предоставить пользователям гибкость в управлении данны64
ми и преобразовании чертежей программы AutoCAD в форматы
файлов, которые могли читаться и использоваться другими САПР.
Из-за популярности AutoCAD формат DXF стал фактическим стандартом обмена файлами CAD-чертежей почти для всех САПР. На
самом деле почти в каждой из появляющихся новых САПР имеется
транслятор в формат DXF и обратно.
DXF-файл – это текстовый ASCII-файл, состоящий из пяти разделов: Header (Заголовок), Table (Таблица), Block (Блок), Entity
(Элемент) и Terminate (Конец).
В разделе Header описывается среда AutoCAD, в которой был
создан DXF-файл. В разделе Table содержится информация о типах
линий, слоях, стилях текста и видах, которые могут быть определены на чертеже.
В разделе Block содержится список графических элементов,
определенных как группа. Конкретные данные по каждому элементу хранятся в соответствующем разделе Entity, который следует сразу за разделом Block.
Раздел Entity – это главный раздел DXF-файла, в котором описываются все элементы, присутствующие на чертеже.
Аналогично тому как это происходило с IGES-файлами, с появлением новых версий AutoCAD список возможных элементов DXFфайлов расширялся. DXF-файл, созданный более поздней версией
AutoCAD, не может быть прочитан другими системами, использующими более старые версии формата DXF.
3.3. Принципы построения международных стандартов
Форматы IGES и DXF были разработаны для обмена данными
технических требований, а не данными о продукте [5]. Под данными о продукте мы понимаем данные, относящиеся ко всему
жизненному циклу продукта (например, проектирование, производство, контроль качества, испытания и поддержка). Хотя
спецификации IDES и DXF были расширены с целью включения
некоторых из этих данных, информации, содержащейся в этих
файлах, по существу недостаточно для описания всего жизненного цикла продукта. Вследствие этого в США в 1983 году началась
разработка нового стандарта под названием PDES (Product Data
Exchange Specification – спецификация для обмена данными о
продуктах). Основной упор в PDES делался не на обмен данными
технических требований, а на то, чтобы исключить человеческое
65
присутствие из обмена данными о продукте. Иначе говоря, целью
PDES было устранить потребность в инженерных чертежах и других бумажных документах при обмене информацией о различных
фазах жизненного цикла продукта между сходными или различающимися САПР. Между тем в июле 1984 года в Международной
организации по стандартизации (ISO) были образованы технический комитет ТС 184 (Системы промышленной автоматизации) и
его подкомитет SC4 (Внешнее представление данных о модели продукта) для установления единого международного стандарта обмена данными о модели продукта – STEP (STandard for Exchange
of Product model data) [12]. Цели PDES и STEP были идентичны,
поэтому в июне 1985 года Управляющий комитет IGES решил, что
интересы США в программе STEP должен представлять стандарт
PDES. В результате значение акронима PDES поменяли на «обмен данными о продукте с использованием STEP» (Product Data
Exchange using STEP), чтобы подчеркнуть идентичность целей
PDES и STEP.
В основе разработки STEP лежат следующие принципы.
1. Стандарт STEP должен ориентироваться на данные о продукте, которые включают информацию обо всем жизненном цикле
изделия: проектировании, производстве, контроле качества, испытании и поддержке. Таким образом, в качестве данных должна
рассматриваться информация о допусках, технологических особенностях формы, конечноэлементная модель, модель для кинематического анализа и т. д., а также данные технических требований,
относящиеся главным образом к форме продукта.
2. В структурах данных STEP информация, относящаяся к приложению, должна храниться в модуле уровня приложения, отдельно от общей информации о форме. Благодаря такому подходу
структура данных сможет поддерживать широкий спектр приложений, избегая при этом избыточности в общей структуре данных.
3. Для определения структуры данных должен использоваться
формальный язык. Спецификации IGES и DXF описывают формат
физического файла, в котором хранятся все геометрические и прочие данные. В STEP данные описываются на языке EXPRESS, а затем результат преобразовывается в физический файл. Таким образом можно избежать неоднозначностей при интерпретации данных
о продукте, извлеченных из файла.
В STEP используются следующие важные понятия:
AAM – Application Activity Model; это функциональная модель
для определенного приложения;
66
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).
Ряд томов переведен на русский язык и представлен в виде
национальных стандартов России. Это, например, ГОСТ Р ИСО
67
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.
Базовый для STEP-технологий язык Express описан в стандарте ISO 10303, том 11. Язык является объектно-ориентированным,
имеет универсальный характер, его можно использовать для описания статических структур и их свойств в различных предметных
областях, несмотря на то, что язык разрабатывался прежде всего
в качестве средства представления моделей промышленных изделий на разных этапах их жизненного цикла. Описание некоторого
приложения на языке Express в рамках стандартов STEP называют
Express-моделью (мodel). В модели декларируются множества понятий и объектов, входящих в приложение, свойства и взаимосвязи объектов. Модель состоит из одной или нескольких частей, называемых Express-схемами (schema) или просто схемами, и обменного файла. Схема – раздел описания, являющийся областью определения данных. В ней вводятся необходимые типы данных. При
описании свойств типов данных могут применяться средства процедурного описания – процедуры, функции, правила, константы.
Обменный файл содержит конкретные экземпляры типов данных.
Описание схемы начинается с заголовка, состоящего из служебного слова schema и идентификатора – имени схемы. Далее следует
содержательная часть – тело схемы. Описание заканчивается служебным словом end_schema:
SCHEMA <имя_схемы>;
<тело_схемы>;
END_SCHEMA;
Для установления интерфейса между двумя схемами вводятся
спецификации интерфейса. Применяют два типа спецификаций –
use и reference. Например:
SCHEMA s1;
ENTITY par1;
name: STRING;
END_ENTITY;
END_SCHEMA;
68
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
модель размещается более чем на одной странице, используется
овальный символ, внутри которого указываются через запятую номер страницы и номер ссылки.
Первая группа документов – тома 11–19 – отведена для описания диалектов языка Express.
N = 11: 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 – расширение языка, предназначенное для описания отдельных экземпляров данных.
69
N = 14: Express-X – дополнение к языку Express, применяемое
для описания соответствий между типами данных в заданной исходной Express-схеме и создаваемыми новыми ее вариантами (views);
в качестве views могут использоваться форматы с описанием того
же множества сущностей, что и в Express-схеме, формат IGES.
Предлагаются и другие дополнения, относящиеся к следующим
диалектам языка Express:
Express-M: Mapping definition language – язык, аналогичный
Express-X, для описания соответствий между сущностями и атрибутами некоторых моделей, представленных в виде схем на языке
Express. Например, этими схемами могут быть два разных прикладных протокола, имеющих частично общие данные, или две
схемы одного приложения, но созданные разными лицами (при отсутствии соответствующего АР). Одна схема есть схема-источник,
другая – целевая схема. Целевых схем может быть несколько при
одной схеме-источнике. Предложения Express-M транслируются
на язык С, результирующая программа представляет собой совокупность обращений к функциям базы данных SDAI в STEP-среде.
Другими словами, транслятор относится к системе SDAI, определяемой в протоколе ISO 10303-22, a Express-M можно рассматривать
как язык 4GL для обращений к функциям базы данных SDAI;
Express-P: Process definition language – язык диаграмм для
представления процессов, методов и коммуникационных структур;
Express-V: язык, предназначенный для получения ARMпредставлений из АIМ-моделей, другими словами, для описания
процедур поиска экземпляров Express-объектов, отвечающих заданным условиям, и доступа к ним, например при создании новых
ARM. Эти создаваемые ARM-представления обычно не требуют
столь всестороннего описания приложения, как в AIM, и потому
могут быть существенно проще. В Express-V имеются:
схема-источник (AIM); обычно это прикладной протокол, например АР203;
схема-цель, задающая сущности, которые должны быть
в создаваемой частной модели;
схема отображения нужных сущностей из источника в цель. На
языке Express-V описываются условия (в виде клонов WHEN) такого
отображения. Берется подходящая уже существующая AIM как источник, все совпадающие объекты переводятся в ARM, далее описываются оригинальные объекты. Дополнительной возможностью реализаций Express-V является обратное отображение специфики создаваемой ARM в исходную AIM с целью развития прикладных протоколов.
70
Для возможности применения языка 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; содержит
описание SDA1 – системы представления данных и доступа к данным конкретных прикладных систем (чаще всего это CAD/CAMсистемы). Данные, участвующие в межпрограммных связях, образуют SDAI-модели. В SDAI-системе предусматривается компилятор кода, конвертирующего эти модели в SDAI-базу данных, а
также функции обращения к этой базе данных. Возможно непосредственное построение прикладных систем, работающих с SDAIбазой данных.
Тома 23–29 устанавливают правила обращения к данным
в SDAI-базе данных на языках программирования C++, С, Java, на
языке передачи данных в системах распределенных вычислений
IDL, языке разметки XML.
Остальные тома стандарта ISO 10303 посвящены описанию тестирования моделей, представленных на языке Express, интегрированным ресурсам, прикладным протоколам и прикладным компонентам.
Контрольные вопросы
1. Перечислите основные стадии проектирования изделий по
ГОСТ.
2. Какие группы стандартов включены в ЕСКД?
3. Объясните, для каких целей при обмене графической информацией между подсистемами САПР применяют нейтральные файлы, назовите два их популярных формата.
71
4. Какие этапы жизненного цикла изделия охватывает стандарт
STEP?
5. Что означает термин «Прикладной протокол» в международном стандарте STEP?
6. Является ли язык Express языком программирования высокого уровня?
72
4. ИНТЕГРАЦИЯ САПР
В ОБОБЩЕННЫЕ ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ
4.1. Развитие интеграционных процессов
В настоящее время прогресс в области создания САПР как инструментария проектировщика определяется теми ИНТЕХ, которые позволяют проектировщику учитывать весь ЖЦИ. На предприятиях создаются интегрированные САПР, охватывающие все
аспекты и уровни проектируемого изделия.
Успешное воплощение идей интегрированных САПР требует
развития принципов построения и функционирования САПР в следующих направлениях.
1. Внедрение принципа независимости данных и программ, т. е.
возможность извлечения данных из любой базы данных (БД) при
наличии стандартных интерфейсов между БД и прикладными программами. Это необходимо для адаптации инструментов САПР.
2. Рациональное применение унифицированных, стандартизованных типовых компонентов, комплексов технических средств,
программно-методических комплексов и проектных решений.
3. Минимизация документооборота за счет широкого использования принципа информационной совместимости подсистем САПР,
в результате чего возможна конвейерная обработка информации.
4. Широкое применение интеллектуальных рабочих станций.
5. Основой интеграции информационных ресурсов всех подсистем САПР является распределенная база данных на машинных
носителях и локальная вычислительная сеть. Ядром информационных ресурсов системы является вычислительный комплекс на
базе мощной ЭВМ. Этот комплекс связан единой сетью ЭВМ с интеллектуальными рабочими станциями (ИРС) и автоматизированными рабочими местами (АРМ).
Развитие интегрированных САПР началось в 80-е годы 20
века с появления CIM-систем (Computer Integrated Business of
Manufacturing) [3]. CIM-системы обеспечивали интеграцию систем CAD и CAM – (Computer Aided Design/Computer Aided
Manufacturing), на основе общей проектной и производственной
базы данных, содержащей взаимосвязанную комбинацию программных и технических средств для проектирования изделий,
планирования и управления как процессом проектирования, так
и производством, а также для автоматизации производственных
процессов.
73
Основу CIM-систем составляли методы и процессы, включающие
в себя вопросы анализа, планирования, проектирования систем
с числовым программным управлением (ЧПУ), робототехники,
групповой технологии, контроля, отладки, тестирования и другие.
Системный подход к построению CIM-систем требует рассмотрения в системном единстве трех функциональных подсистем автоматизации.
1. Исследовательское проектирование. Эта подсистема ориентирована на выбор и принятие принципиальных технических решений по главным структурным компонентам изделия, т. е. выбор
принципа действия, разработка структурной и функциональной
моделей и их оптимизация, синтез (построение) математических
моделей и проведение соответствующих модельных экспериментов
над изделием в целом и др.
2. Типовое конструкторско-технологическое проектирование и
испытания. Эта подсистема представляет собой совокупность линий сквозного проектирования – от разработки частного технического задания до технологической документации (включая ЧПУпрограммы) по основным классам компонентов изделия. Процесс
проектирования в таких линиях последовательно проходит 4 этапа: разработка схем, конструирование, технологическое проектирование, испытания.
3. Управление разработкой проекта и развитие CIM-системы.
Главная задача этой подсистемы состоит в том, чтобы увязать процесс
автоматизированного проектирования с его ресурсным обеспечением
по таким задачам, как управление опытным производством, выпуск
организационно-технической документации, управление процессом
проектирования и испытаниями, график разработки проекта, создание информационных ресурсов в виде автоматизированных процедур для решения новых задач в управлении и проектировании
путем регулярного проведения процедуры обследования (системного
анализа и оценки состояния инструментальных средств, систем проектирования и управления) на данном предприятии и другие).
В соответствии с принципами создания сложных многоуровневых систем автоматизированного проектирования интегрированная САПР строилась как трехуровневая система, содержащая на
верхнем уровне центральный вычислительный комплекс (ЦВК)
для хранения больших объемов информации и решения очень
сложных и трудоемких задач; на втором уровне – интеллектуальные рабочие станции, автоматизированные рабочие места и на третьем уровне – интеллектуальные терминалы для выполнения про74
стых инженерных задач и периферийное программно-управляемое
оборудование. Аналогичные принципы применяются при проектировании современных интегрированных систем.
В начале 80-х стоимость одного рабочего места, т. е. одной лицензии составляла примерно 90–100 тысяч $.Возможности систем
на то время определялись характеристиками имеющихся графических аппаратных средств. В основном использовались графические
терминалы, которые подключались к мэйнфреймам, или к миниЭВМ типа PDP/11.Применялись компьютеры компаний CDC и IBM.
В начале 90-х системы стали доступней, стоимость снизилась до
20000 $. Поставщики средств автоматизации проектирования использовали компьютеры на базе RISC-процессоров. Они работали
под управлением ОС Unix и были намного дешевле минимашин,
мэйнфреймов. Позже Autodesk разработала пакет AutoCAD, который стоил всего одну тысячу долларов и приобрел довольно большую
популярность среди пользователей. Были созданы предпосылки для
создания CAD/CAM/CAE-систем для более широкого применения.
В 90-х годах на рынке появились новые компании, которые заполнили пробел между дорогими продуктами и программами типа
AutoCAD, они обладали богатыми функциональными возможностями. Это стало возможным, благодаря появлению системы Windows
NT, а компания Intel выпустила процессор Pentium Pro. Как раз в то
время САПР разделился на классы: тяжелый, средний и легкий; они
различны по цене и по функциональным возможностям. К тяжелому
классу относятся продукты: Unigraphics NX, Pro/Engineer, CATIA,
EUCLID, I-DEAS; к среднему классу SolidWorks, CadKey, Inventor
и Mechanical Desktop PowerSolutions, Cimatron, T-Flex, КОМПАС
(CAD/CAM/CAE/PDM); в легкий класс входят системы AutoCAD,
DataCAD, SurfCAM 2D, IntelliCAD, Medusa, TrueCAD и т. д. Это
лишь часть довольно известных продуктов, представленных на мировом рынке. Кроме этого существуют еще и специализированные
САПР для строительного, промышленного, архитектурного проектирования. Для дальнейшего развития после 90-х годов характерна
интеграция CAD/CAM/CAE-систем с системами информационной
поддержки изделий, что привело к появлению PDM-систем [13].
PDM-система (Product Data Management), дословно – «Управление
данными об изделии». Это система управления производственной
информацией. Инструментальное средство, которое помогает администраторам, инженерам, конструкторам и так далее управлять как
данными, так и процессами разработки изделия на современных производственных предприятиях или группе смежных предприятий.
75
Представление данных на изделие только в виде документов,
пусть даже и в электронном виде, приводит к сложности, когда эти
данные необходимо извлекать из документов. Для решения этой
задачи необходимо комбинированное хранилище данных и документов об изделии. Вопросами управления формализованными
и неформализованными данными занимается PDM-технология,
класс автоматизированных систем (АС), реализующих данную технологию, носит название PDM-систем.
При построении электронного архива конструкторской документации необходимо заложить основу для системы по хранению и обмену данными, выделить формализованные данные об изделии (состав, атрибуты изделия), обеспечить хранение истории изменения
данных об изделии, т. е. разработать структуру хранения данных.
Важной составляющей создаваемого архива является создание справочной подсистемы. Общая идеология применения PDMтехнологии предполагает, что все справочные данные, необходимые для проектирования изделия, хранятся в PDM-системе.
Детальная проработка структуры и регламентов работы со справочной подсистемой необходима на самом первом этапе создания
электронного архива. Создаваемый архив должен содержать не
просто копии электронной документации, сданная электронная
документация должна пройти процедуры утверждения, т. е. необходима разработка регламента сдачи документации в архив.
Отечественные нормативные документы в сфере электронного документооборота нуждаются в актуализации. Реализация электронного документооборота в точном соответствии ГОСТ 28388-89
«Документы на магнитных носителях» технически и организационно сложна, большинство отечественных предприятий не готово осуществлять нормоконтроль и согласование документации
в электронном виде.
Наполнение данных и электронного архива на первой стадии –
создании электронного архива, осуществляется операторами, входящими в состав отдела технической документации (ОТД) – это позволяет сохранить легальность вводимых данных и практически не
влияет на процессы работы большинства работников предприятия.
Одновременно с созданием электронного архива документации,
подразделения предприятия получают возможность получать не
только электронные документы, но и необходимые им данные об
изделии (состав, масса, применяемость изделия и т. п.). Электронный архив на базе PDM-системы, таким образом, является архивом
и данных, и документов.
76
Следующим этапом в развитии системы является применение
технологии управления потоками работ (Work Flow), позволяющей
осуществлять автоматизированное согласование электронных данных и документов. На этом этапе также параллельно существую и
бумажный и электронный документооборот. Автоматизированное
согласование документов позволяет снизить роль бумажного документооборота за счет того, что все изменения и отметки о согласовании электронных документах фиксируются PDM-системой.
Бумажные подлинники при применении такого способа согласования подписываются либо параллельно с бумажным согласованием,
либо по завершении согласования электронных документов. Подлинником с юридической точки зрения являются бумажные документы, подписанные всеми заинтересованными лицами.
Наиболее широко функциональные возможности PDM-систем
используются на третьем этапе, когда к архивным и согласующим
функциям прибавляются функции по управлению данными при
непосредственной разработке изделия конструкторами. На этом
этапе PDM-система исполняет роль рабочего архива конструктора, предоставляя ему все необходимые данные для разработки изделия, позволяет генерировать часть конструкторских документов
в виде отчетов на основе данных об изделии, хранить информацию
о проработке различных вариантов конструкции. Для реализации подобной схемы работы необходимо интегрировать с PDMсистемой все прикладные АС, используемые в проектировании
изделия, это позволит избежать ввода одной и той же информации
по нескольку раз на разных стадиях проектирования. Ввод данных
осуществляется непосредственными разработчиками этих данных
и в дальнейшем источником этих данных для всех потребителей
является архив на основе PDM-системы.
Переход к использованию ИНТЕХ-управления данными позволит
перестроить процесс разработки изделия, сократив временные издержки за счет большей эффективности доступа и согласования данных.
Применение электронной цифровой подписи возможно на любой из стадий развертывания электронного архива на основе PDMсистемы, но ее полноценное внедрение повлечет за собой изменение
процессов обработки данных и документов, а также возможно необходимость доработки уже используемого программного обеспечения.
Разделение на конструкторские и производственные организации, существовавшее в советское время, практически полностью
унаследованное российской машиностроительной отраслью, ставит дополнительные задачи по обмену конструкторскими данными
77
и документами. Став независимыми юридически отечественные
предприятия все также тесно связаны между собой. Такое разделение ставит задачу по обмену данными между предприятиями, а
именно между ИНТЕХ этих предприятий. В условиях рынка необходимы универсальные решения по обмену данными, разработка
подобных универсальных решений подразумевает отсутствие привязанных к конкретным ИНТЕХ. Создание «виртуальных» предприятий, о которых много дискутируют в последнее время, невозможно без разработки универсальных механизмов обмена данными. Работы в области обмена данными об изделии в универсальных
форматах активно ведутся во всем мире, в основе большинства
этих работ лежат технологии, заложенные стандартом ISO 10303
(STEP). Организация автоматизированного обмена данными и документами подразумевает наличие на предприятиях легальных
электронных архивов, содержащих актуальные данные.
Постоянное повышение сложности разрабатываемых изделий
и требований, предъявляемых рынком, приводит к неизбежному
росту объемов данных. Создание ИНТЕХ-управления данными об
изделии в этом аспекте становится жизненно необходимым.
Исходя из направления развития как отдельных предприятий,
так и общего развития машиностроительной отрасли, неизбежно
придется создавать электронные архивы конструкторской документации, но надо также четко осознавать, что определенное переходное время на предприятии будет существовать параллельно и
бумажный, и электронный документооборот.
4.2. Место САПР в CALS-технологиях
Первые шаги в организации единого информационного пространства были предприняты еще в 80-х годах. Возникла необходимость в обеспечении оперативного обмена данными между заказчиком, производителем и потребителем техники, а также в повышении управляемости, сокращении бумажного документопотока и
связанных с ним затрат. Данная концепция изначально базировалась на понятии ЖЦИ и охватывала в основном фазы производства
и эксплуатации. На первоначальном этапе инициатива получила
обозначение CALS (Computer Aided Logistic Support – компьютерная поддержка поставок).
Доказав свою эффективность, концепция CALS начала активно применяться в промышленности, строительстве, транспорте и
78
других отраслях экономики, расширяясь и охватывая все этапы
ЖЦИ – от маркетинга до утилизации.
Новая концепция сохранила существующую аббревиатуру (CALS), но получила более широкую трактовку: Continuous
Acquisition and Life cycle Support – непрерывная информационная поддержка жизненного цикла продукта. Таким образом, идея,
связанная только с поддержкой логистических систем, быстро
превратилась в глобальную бизнес-стратегию перехода на безбумажную электронную технологию и повышения эффективности
бизнес-процессов, выполняемых в ходе ЖЦИ за счет информационной интеграции и совместного использования информации на
всех этапах ЖЦИ. В настоящее время в мире действует более 25
национальных организаций, координирующих вопросы развития
CALS-технологий, в том числе в США, Канаде, Японии, Великобритании, Германии, Швеции, Норвегии, Австралии, а также
в рамках НАТО.
В отличие от интегрированной автоматизированной системы
управления производством (ИАСУ), CALS-система охватывает все
стадии ЖЦИ. Информационная интеграция базируется на применении следующих интегрированных моделей:
продукта;
ЖЦИ и выполняемых в его ходе бизнес-процессов;
производственной и эксплуатационной среды. С позиций системной архитектуры базовые информационные модели – это фундамент, на котором могут быть построены автоматизированные
системы управления различного уровня. На основе одной и той
же модели ЖЦИ и бизнес-процессов решаются задачи анализа эффективности бизнес-процессов и обеспечения качества продукции.
Интегрированная модель продукта обеспечивает обмен конструкторскими данными между проектировщиком и производителем,
является источником информации для расчета потребности в материалах и создания электронных справочников по эксплуатации
продукта и т. д. Применение совместно используемых информационных моделей, являющихся единым источником информации и
стандартизованных методов доступа к данным, – основа эффективной информационной кооперации всех участников ЖЦИ.
Например, с помощью CALS-технологий решаются задачи моделирования жизненного цикла продукта и выполняемых бизнес-процессов. Первый шаг к повышению эффективности организационной
структуры, поддерживающей одну или несколько стадий ЖЦИ, –
моделирование и анализ ее функционирования. Цель бизнес-ана79
лиза – выявить существующее взаимодействие между составными
частями и оценить его рациональность и эффективность. Для этого с использованием CALS-технологий разрабатываются функциональные модели, содержащие детальное описание выполняемыx
процессов в их взаимосвязи. Формат описания регламентирован
стандартами IDEF/0 и ISO 10303 AP208. Полученная функциональная модель не только является детальным описанием выполняемых
процессов, но также позволяет решать целый ряд задач, связанных
с оптимизацией, оценкой и распределения затрат, оценкой функциональной производительности, загрузки и сбалансированности
составных частей, т. е. вопросов анализа и реинжиниринга бизнеспроцессов (Business Process Reengineering, BPR).
При проектировании и производстве изделия применяется совместное, кооперативное проектирование и производство изделия,
которое может быть эффективным в случае, если оно базируется на
основе единой информационной модели изделия.
Во многих развитых странах CALS рассматривается как стратегия выживания в рыночной среде, позволяющая:
расширить области деятельности предприятий (рынки сбыта)
за счет кооперации с другими предприятиями, обеспечиваемой
стандартизацией представления информации на разных стадиях
и этапах жизненного цикла. Благодаря современным телекоммуникациям, уже не принципиально географическое положение и
государственная принадлежность партнеров. Новые возможности
информационного взаимодействия позволяют строить кооперацию
в форме виртуальных предприятий, действующих в течение ЖЦИ.
Становится возможной кооперация не только на уровне готовых
компонентов, но и на уровне отдельных этапов и задач: в процессах
проектирования, производства и эксплуатации;
повысить эффективность бизнес-процессов, выполняемых в течение ЖЦ продукта; за счет информационной интеграции и сокращения затрат на бумажный документооборот, повторного ввода и
обработки информации обеспечить преемственность результатов
работы в комплексных проектах и возможность изменения состава
участников без потери уже достигнутых результатов;
повысить “прозрачность” и управляемость бизнес-процессов путем их реинжиниринга, на основе интегрированных моделей ЖЦИ
и выполняемых бизнес-процессов, сократить затраты в бизнес-процессах за счет лучшей сбалансированности звеньев;
повысить привлекательность и конкурентоспособность изделий, спроектированных и произведенных в интегрированной среде
80
с использованием современных компьютерных технологий и имеющих средства информационной поддержки на этапе эксплуатации;
обеспечить заданное качество продукции в интегрированной
системе поддержки ЖЦИ путем электронного документирования
всех процессов и процедур.
По инициативе и при поддержке Сводного департамента экономики оборонных отраслей промышленности в сети Интернет
создан информационный сервер по вопросам разработки и применения CALS-технологий в России (www.cals.ru), содержащий, помимо новостей, описаний продуктов и технологий, информацию
о международных CALS-стандартах (STEP, SGML, HyTime, Plib,
MANDATE).
Сейчас большинство производственных предприятий в разных
сферах деятельности используют САПР как основную часть CALSтехнологий проектирования и процессов автоматизированных системы. В конструкторских и технологических отделах добавляют
к САПР АСУТПМЗ, в других отделах работают бухгалтерские программы. В сфере управления постепенно заменяют учетно-складские приложения на полноценные системы управления предприятием, а к САПР добавляют систему управления инженерными
данными и начинают переход от автоматизации проектирования
к управлению информацией об изделии на протяжении всего его
жизненного цикла. Таким образом, одной из важнейших задач
в настоящее время является задача интеграция САПР с другими
пакетами прикладных программ или системами. Вспомним, что
главная задача интеграции – обеспечить возможность использование данных одной подсистемы или системы другой системой (подсистемой) без дополнительного ручного ввода информации.
Рассмотрим наиболее популярные системы, применяемые на
промышленных предприятиях, объединяемых с САПР [3, 4, 13].
CAM – Computer Aided Manufacturing. Системы автоматизированной подготовки производства, подготовки информации для
станков с ЧПУ. Традиционно исходными данными для таких систем были геометрические модели деталей, полученных из систем
CAD. CAD – Computer Aided Design.
CAE – Computer Aided Engineering. Автоматизированная система научных исследований. Предназначена для автоматизации
предварительного анализа проекта, а также для информационного
обеспечения предпроектного анализа проекта, имеет целью обнаружение ошибок или оптимизацию проектно-производственных
возможностей.
81
ERP – Enterprise Resource Planning. Комплексные системы
управления предприятием (АСУП), осуществляющие управление
финансами и бухгалтерский учет, управление поставками и сбытом (логистический модуль), управление кадрами, управление
проектами и планированием.
PDM – Product Data Management. Системы управления данными о проекте предназначены для хранения проектных данных и доступа к ним, в том числе для ведения распределенных архивов документов, их поиска, редактирования, маршрутизации, создания
спецификаций.
АСУТП – автоматизированные системы управления технологическими процессами. Осуществляются сбор и обработка данных о
состоянии оборудования и протекании производственных процессов для принятия решений по загрузке станков и выполнению технологических маршрутов. В АСУТП выполняются запуск, тестирование, выключение станков, сигнализация о неисправностях, выработка управляющих воздействий для рабочих органов программно управляемого оборудования.
SCADA – Supervisory Control and Data Acquisition. Автоматизированная система диспетчерского управления, сбора, обработки,
представления и архивирования данных, поступающих из различных цехов и участков предприятия и различных подсистем
АСУТП.
MRP – Material Requirement Planning. Концепция и методология эффективного планирования ресурсов производственного предприятия. Включает бизнес-планирование, планирование продаж и
операций, формирование главного календарного плана производства, планирование потребности в материалах, в мощностях; обеспечивает поддержку исполнения планов для производственных
мощностей и материалов.
CRM – Customer Relationship Management. Система, на вход которой поступают данные, связанные с клиентами компании, а на
выходе появляется информация, влияющая на поведение компании в целом или на поведение ее отдельных элементов (вплоть до
конкретного работника компании).
Задачи интеграции САПР с другими средствами ИНТЕХ наиболее качественно призваны решать системы обеспечения всего
ЖЦИ. ЖЦИ, как его определяет стандарт ISO 9004-1, – это совокупность процессов, выполняемых от момента выявления потребностей общества в определенной продукции до удовлетворения
этих потребностей и утилизации продукта.
82
Информационное взаимодействие субъектов, участвующих в поддержке ЖЦИ, должно осуществляться в едином информационном
пространстве. В основе концепции единого информационного пространства лежит использование открытых архитектур, международных стандартов и апробированных коммерческих продуктов обмена данными. Стандартизации подлежат форматы представления
данных, методы доступа к данным и их корректной интерпретации.
4.3. Унификация форм документации на изделие
в едином информационном пространстве
Промышленные САПР могут работать автономно, и в настоящее
время так обычно и происходит. Однако эффективность автоматизации будет заметно выше, если данные, генерируемые в одной из
систем, будут доступны в других системах, поскольку принимаемые в них решения станут более обоснованными.
Чтобы достичь должного уровня взаимодействия промышленных САПР, требуется создание единого информационного пространства в рамках как отдельных предприятий, так и, что более
важно, в рамках объединения предприятий. Единое информационное пространство обеспечивается благодаря унификации как формы, так и содержания информации о конкретных изделиях на различных этапах их жизненного цикла.
Унификация формы достигается использованием стандартных
форматов и языков представления информации в межпрограммных обменах и при документировании.
Унификация содержания, понимаемая как однозначная правильная интерпретация данных о конкретном изделии на всех этапах его жизненного цикла, обеспечивается разработкой онтологий
(метаописаний) приложений, закрепляемых в прикладных протоколах CALS.
Унификация перечней и наименований сущностей, атрибутов и
отношений в определенных предметных областях является основой
для единого электронного описания ЖЦИ в CALS-пространстве.
В общем случае ЖЦИ необходимо рассматривать как совокупность ЖЦИ конечного продукта и ЖЦИ входящих в него компонентов. Информационное взаимодействие субъектов, участвующих
в поддержке ЖЦИ, должно осуществляться в едином информационном пространстве. В основе концепции единого информационного
пространства лежит использование открытых архитектур, междуна83
родных стандартов и апробированных коммерческих продуктов обмена данными. Стандартизации подлежат форматы представления
данных, методы доступа к данным и их корректной интерпретации.
Разрабатываемая на данной фазе конструкторско-технологическая информационная модель должна базироваться на использовании стандарта ISO 10303 STEP. Созданная однажды модель
изделия используется многократно. В нее вносятся дополнения и
изменения, она служит отправной точкой при модернизации изделия. Модель изделия в соответствии с этим стандартом включает:
геометрические данные, информацию о конфигурации изделия,
данные об изменениях, согласованиях и утвержденных.
Стандарт ISO 10303 построен таким образом, что помимо базовых элементов (интегрированных ресурсов) в его состав входят так
называемые прикладные протоколы, определяющие конкретную
структуру информационной модели для различных предметных
областей (автомобилестроение, судостроение, строительство, электроника и т. д.). Все прикладные протоколы (прикладные информационные модели) базируются на стандартизованных интегрированных ресурсах. Таким образом, при создании нового прикладного протокола обеспечивается преемственность с уже существующими решениями.
Стандартный способ представления конструкторско-технологических данных позволяет решить проблему обмена информацией между различными подразделениями предприятия, а также
участниками кооперации, оснащенными разнородными системами проектирования. Использование международных стандартов
обеспечивает корректную интерпретацию хранимой информации,
возможность оперативной передачи функций одного подрядчика
другому, который, в свою очередь, может воспользоваться результатами уже проделанной работы. Это особенно важно для изделий
с длительным ЖЦИ, когда необходимо обеспечить преемственность информационной поддержки продукта, независимо от складывающейся рыночной или политической ситуации
Известно, что объемы разрабатываемой на этапе эксплуатации
документации для сложного наукоемкого изделия очень велики.
Поэтому традиционное бумажное документирование сложных изделий требует огромных затрат на поддержку архивов, корректировку документации, а также снижает эксплуатационную привлекательность и конкурентоспособность изделия.
Решение проблемы заключается в переводе эксплуатационной
документации на изделие, поставляемой потребителю, в унифици84
рованный электронный вид. При этом комплект электронной эксплуатационной документации следует рассматривать как составную
часть единой интегрированной информационной модели изделия.
Электронная документация может поставляться на электронных носителях, например компакт-дисках, или размещаться в глобальной сети Интернет. Эксплуатационная документация может
содержать информацию различных типов в соответствии со стандартами CALS: ISO 8879 (SGML), ISO 10744 (HyTime) и MIL-PRF28001C – для текстовой и мультимедийной информации; MIL-PRF28000A, MIL-PRF-28002C, MIL-PRF-28003A – для векторных и
растровых графических иллюстраций.
Стандарты MIL-PRF-87268 и MIL-PRF-87269 определяют стиль,
формат и технологию создания электронных справочников по изделиям. Стандартизация гарантирует применимость такой электронной документации на любых компьютерных платформах.
Важно отметить, что в электронный вид может быть преобразована эксплуатационная документация, созданная ранее без использования компьютерных систем. Для изделий, уже находящихся
в эксплуатации длительный период и спроектированных традиционными методами, задача поддержки документации не менее актуальна. Электронная документация размещается в специальных
хранилищах или непосредственно у производителей и доступна через компьютерные сети. Одновременно информация может распространяться на компакт-дисках. Данные работы выполняются уже
в течение ряда лет. При этом используются современные технологии сканирования, распознавания текста, векторизации чертежей
и схем, создаются электронные справочники на целые изделия и
отдельные системы.
Контрольные вопросы
1. Кто является пользователем PDM-системы?
2. Какие этапы жизненного цикла изделия охватывают PDMсистемы?
3. Какие автоматизированные системы применяются на промышленных предприятиях совместно с САПР?
4. Какие этапы жизненного цикла изделия охватывают CALSсистемы?
5. В чем заключаются задачи внедрения CALS-систем?
6. Какие задачи решаются с помощью создания единого информационного пространства?
85
5. ПРИМЕНЕНИЕ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ
ОРГАНИЗАЦИИ И УПРАВЛЕНИЯ ПРИ ВНЕДРЕНИИ САПР
5.1. Применение информационных технологий
управления проектами
При внедрении САПР требуется применение современных
средств организации и управления проектно-автоматизированными и поддерживающими их процессами. Для этих целей используются системы управления проектами [14, 15], обеспечивающие основной набор функциональных возможностей, которые включают:
средства проектирования структуры работ по проекту;
средства планирования по методу критического пути;
средства планирования ресурсов;
стоимостный анализ;
средства контроля над ходом выполнения проекта;
средства составления отчетов, построения графиков и диаграмм.
Наряду с этими функциями наиболее распространенные пакеты по
управлению проектами могут выполнять дополнительные функции:
анализ рисков;
учет рабочего времени исполнителей;
расчет расписания при ограниченных ресурсах;
интеграция систем управления проектами в корпоративные
управленческие системы;
настройка универсальных пакетов на специфику конкретной
области.
Программное обеспечение для управления проектами разделяется на профессиональные системы и системы массового пользователя,
Профессиональные пакеты представляют собой гибкие средства
реализации функций планирования и контроля, но они требуют
значительных финансовых вложений, больших затрат времени на
подготовку и анализ данных, высокой квалификации пользователей. Основной характеристикой пакетов массового пользователя
является более низкая стоимость, простота использования и скорость получения результата. Наиболее известные пакеты по управлению проектами приведены в табл. 5.1.
В последние годы в средства управления проектами интегрированы возможности коммуникаций (электронная почта и Интернет).
В настоящее время все основные производители программного обеспечения для управления проектами представлены в России. Одна
86
Таблица 5.1
Пакеты прикладных программ по управлению проектами
Пакет
Artemis Project View
Open Plan Professional
Primavera Project Planner
Open Plan Desktop
Project 98
Project Scheduler
CA-Super Project
Sure Trak Project Manager
Time Line
AutoPLAN II
Project Workbench PMW
SAS/OR
Infinium
PLATINUM Process Continuum
MacProjectPro
Plan Vien
Производитель
Artemis International
Welcom Software Technology
Primavera Systems, Inc.
Welcom Software Technology
Microsoft
Scitor Corp.
Computer Associates, Inc.
Primavera Systems, Inc.
Time Line Solutions Corp.
Digital Tools
ABT Corporation
SAS Institute, Inc.
Infinium Software, Inc.
Platinum Technology, Inc.
Claris, Inc.
Plan Vien, Inc.
из фирм, профессионально работающих в области управления проектами, – «Консалтинг ПРИМ». Она представляет на российском
рынке американскую компанию Primavera Systems, которая является лидером среди разработчиков таких пакетов, а также компании RBSI, Primaplan и Inteс, которые в основном решают вопросы
автоматизации дополнительных функций управления проектами.
Приобретение того или иного программного обеспечения не решает всех проблем эффективного управления проектами. Для этого
необходимо создание информационной интегрированной системы
управления проектами. Без создания формализованной системы
руководитель проекта и его участники будут сталкиваться с проблемами, связанными с конфликтами целей, приоритетов, сроков
и отчетности, а автоматизация рутинных функций сбора и обработки информации оставит менеджерам больше времени для анализа
и принятия решений, реализации творческих подходов к управлению проектами.
Интегрированная автоматизированная информационная система
управления проектами имеет как минимум три уровня управления:
уровень стратегического управления;
уровень текущего управления;
уровень исполнения.
87
На уровне стратегического управления решаются вопросы, связанные с утверждением целей, приоритетов и финансирования
проектов, контролем достижения узловых, промежуточных и конечных результатов по этим проектам. На данном уровне управление портфелем проектов осуществляет высшее звено руководства
организации, поэтому здесь требуются простые в использовании
средства сбора и представления информации.
На уровне текущего управления выполняется детальное планирование комплекса работ, ресурсов и контроль проекта по времени
и стоимости. На этом уровне необходимо использование мощных,
гибких аналитических и управленческих средств временного, ресурсного, финансового планирования и контроля, современные
средства сбора, передачи данных и составления отчетов.
На уровне исполнения проекта осуществляется прием информации с уровня текущего управления проектом и из функциональных
подразделений, а также собираются и передаются фактические
данные о выполнении проекта. На этом уровне для команды исполнителей необходимы простые и удобные в использовании средства
ввода и передачи данных.
Внедрение САПР требует применения средств управления, учитывающие рассмотренные выше составляющие этого процесса:
обследование предприятия, разработка или модернизация САПР,
интеграция САПР с другими ИНТЕХ.
Планирование и моделирование процесса внедрения САПР
можно проводить средствами Microsoft Project 2010 [14]. Последовательность действий при этом следующая.
1. Строится файл «Внедрение САПР», определяются его основные характеристики.
2. Определяются сроки начала и окончания процесса внедрения.
3. Определяется состав основных задач, решаемых в процессе
внедрения САПР и ресурсов, используемых для выполнения задач,
предположительная их длительность.
4. Вводятся временные ограничения в задачах, исключаются
повторяющиеся задачи.
5. Создаются связи между задачами.
6. Средствами MS Project производится построение суммарной
задачи (project summary task).
7. Проводится планирование ресурсов, определяется стоимость
ресурсов.
В результате с помощью Microsoft Project можно составить план
внедрения САПР, отследить критические задачи, риски при опре88
делении ресурсов, а также отслеживать процесс внедрения САПР
при его выполнении, т. е. вовремя обнаружить отклонения фактических работ от запланированных.
5.2. Функциональное моделирование процессов
автоматизированного проектирования
При разработке и внедрении автоматизированных систем, результаты обследования предприятия формируются чаще всего
в виде таблиц, и объем информации в них может быть достаточно
большим. В таких случаях, для систематизации этой информации,
а также для глубокого анализа процессов применяются методы
моделирования систем и построенные на их основе программные
пакеты, представляющие собой CASE-средства (Computer-Aided
Software Engineering).
Для моделирования бизнес-процессов на предприятии используется несколько различных методов [16–18], основой которых являются как структурный, так и объектно-ориентированный подходы
к моделированию. Однако деление самих методов на структурные
и объектные является достаточно условным, поскольку наиболее
развитые методы используют элементы обоих подходов. К числу
наиболее распространенных методов относятся:
метод функционального моделирования IDEF0;
метод моделирования процессов IDEF3;
моделирование потоков данных DFD;
метод ARIS.
В основе указанных методов лежит методология SADT, разработанная Дугласом Россом. На ее основе разработана, в частности,
известная методология IDEF0 (Integration Definition for Function
Modeling). Методология IDEF0 представляет собой совокупность
методов, правил и процедур, предназначенных для построения
функциональной модели объекта какой-либо предметной области. Функциональная модель IDEF0 отображает функциональную
структуру объекта, т. е. производимые им действия и связи между
этими действиями. Основные элементы этой методологии основываются на следующих концепциях.
1. Графическое представление блочного моделирования. Графика блоков и дуг IDEF0-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие
89
блоков друг с другом описываются посредством интерфейсных дуг,
выражающих «ограничения», которые в свою очередь определяют,
когда и каким образом функции выполняются и управляются.
2. Строгость и точность. Выполнение правил IDEF0 требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика.
Правила IDEF0 включают:
ограничение количества блоков на каждом уровне декомпозиции (правило 3–6 блоков);
связность диаграмм (номера блоков);
уникальность меток и наименований (отсутствие повторяющихся имен);
синтаксические правила для графики (блоков и дуг);
разделение входов и управлений (правило определения роли
данных);
отделение организации от функции, т. е. исключение влияния
организационной структуры на функциональную модель.
Результатом применения методологии IDEF0 является модель,
которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы – главные компоненты модели, все функции ИС и интерфейсы на них представлены как блоки
и дуги (рис. 5.1). Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты выхода показаны с правой стороны.
Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу.
Одной из наиболее важных особенностей IDEF0 является постепенное введение все больших уровней детализации по мере создания диаграмм, отображающих модель.
Управление
Входы
Функция
Выходы
Механизм
Рис. 5.1. Функциональный блок и интерфейсные дуги в IDEF0
90
Построение IDEF0-модели начинается с представления всей системы в виде простейшей компоненты – одного блока и дуг, изображающих интерфейсы с функциями вне системы. Поскольку единственный блок представляет всю систему как единое целое, имя,
указанное в блоке, является общим. Это верно и для интерфейсных
дуг – они также представляют полный набор внешних интерфейсов
системы в целом.
Затем блок, который представляет систему в качестве единого
модуля, детализируется на другой диаграмме с помощью нескольких блоков, соединенных интерфейсными дугами. Эти блоки представляют основные подфункции исходной функции. Данная декомпозиция выявляет полный набор подфункций, каждая из которых
представлена как блок, границы которого определены интерфейсными дугами. Каждая из этих подфункций может быть декомпозирована подобным образом для более детального представления.
Модель IDEF0 представляет собой серию диаграмм с сопроводительной документацией, разбивающих сложный объект на составные части, которые представлены в виде блоков. Детали каждого
из основных блоков показаны в виде блоков на других диаграммах. Каждая детальная диаграмма является декомпозицией блока
из более общей диаграммы. На каждом шаге декомпозиции более
общая диаграмма называется родительской для более детальной
диаграммы.
Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня, являются точно теми же самыми, что и дуги, входящие в диаграмму нижнего уровня и выходящие из нее, потому что
блок и диаграмма представляют одну и ту же часть системы.
системные требования
1
Разработка
проекта
комментарии
2
Экспертиза
предварительная
спецификация
улучшенный проект
Рис. 5.2. Фрагмент IDEF0-диаграммы с обратной связью
91
На IDEF0-диаграммах не указаны ни последовательность, ни
время. Обратные связи, итерации, продолжающиеся процессы и
перекрывающиеся (по времени) функции могут быть изображены
с помощью дуг. Обратные связи (рис. 5.2) могут выступать в виде
комментариев, замечаний, исправлений и т.д
Модели AS-IS и ТО-ВЕ. Обычно сначала строится модель существующей организации работы – AS-IS (как есть). Модель AS-IS позволяет выяснить, какие процессы функционируют на предприятии
сегодня. Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем будут состоять преимущества
новых автоматизированных процессов и насколько глубоким изменениям подвергнется существующая структура организации работы предприятия. Детализация бизнес-процессов позволяет выявить
недостатки организации даже там, где функциональность на первый
взгляд кажется очевидной. Признаками неэффективной деятельности могут быть бесполезные, неуправляемые и дублирующиеся работы, отсутствие обратных связей по управлению (на проведение работы не оказывает влияния ее результат) и т. д. Найденные в модели
AS-IS недостатки можно исправить при создании модели ТО-ВЕ (как
будет) – модели новой организации бизнес-процессов. Модель нужна
ТО-ВЕ для анализа альтернативных путей выполнения работы и документирования того, как компания будет делать бизнес в будущем.
На рис. 5.3. приведен пример IDEF0-диаграммы, представляющей
процесс проектирования прибора или системы управления (ПСУ).
IDEF3 является технологией, хорошо приспособленной для сбора
данных, требующихся для проведения структурного анализа системы.
В отличие от большинства технологий моделирования бизнеспроцессов, IDEF3 не имеет жестких синтаксических или семантических ограничений, делающих неудобным описание неполных
или нецелостных систем. Кроме того, автор модели избавлен от необходимости смешивать свои собственные предположения о функционировании системы с экспертными утверждениями в целях заполнения пробелов в описании предметной области.
IDEF3-моделирование органично дополняет традиционное моделирование с использованием методологии IDEF0. В настоящее
время оно получает все большее распространение как вполне жизнеспособный путь построения моделей проектируемых систем для
дальнейшего анализа имитационными методами.
Основой модели IDEF3 служит так называемый сценарий бизнес-процесса, который выделяет последовательность действий или
подпроцессов анализируемой системы. Поскольку сценарий опре92
ГОСТ
Подготовка
ТЗ
1
0р
Подготовка
ЭП
2
0р
Исходные
данные
Техническое
проектирование
0р
3
Разработчики
Рабочее
проектирование
0р
4
Комплексирование
отладка испытания
0р
5
Конструкторы
Технологи
Испытатели
Рис. 5.3. Пример IDEF0 диаграммы.
«Этапы процесса проектирования прибора управления»
деляет назначение и границы модели, довольно важным является
подбор подходящего наименования для обозначения действий. Для
подбора необходимого имени применяются стандартные рекомендации по предпочтительному использованию глаголов и отглагольных существительных, например «обработать заказ клиента» или
«применить новый дизайн».
Сценарий для большинства моделей должен быть документирован. Обычно это название набора должностных обязанностей человека, являющегося источником информации о моделируемом процессе.
Главной организационной единицей модели IDEF3 является диаграмма. Взаимная организация диаграмм внутри модели IDEF3
особенно важна в случае, когда модель заведомо создается для последующего опубликования или рецензирования, что является
вполне обычной практикой при проектировании новых систем.
93
В этом случае системный аналитик должен позаботиться о таком
информационном наполнении диаграмм, чтобы каждая из них
была самодостаточной и в то же время понятной пользователю.
Диаграммы IDEF3 отображают действие в виде прямоугольника.
Каждому из действий присваивается уникальный идентификационный номер. Этот номер не используется вновь даже в том случае, если
в процессе построения модели действие удаляется. В диаграммах
IDEF3 номер действия обычно предваряется номером его родителя.
Связи выделяют существенные взаимоотношения между действиями. Все связи в IDEF3 являются однонаправленными, и хотя
стрелка может начинаться или заканчиваться на любой стороне
блока, обозначающего действие, диаграммы IDEF3 обычно организуются слева направо таким образом, что стрелки начинаются на
правой и заканчиваются на левой стороне блоков.
Связь типа «временное предшествование». Связи этого типа показывают, что исходное действие должно полностью завершиться,
прежде чем начнется выполнение конечного.
Связь типа «объектный поток». Одна из наиболее часто встречающихся причин использования связи типа «объектный поток»
заключается в том, что некоторый объект, являющийся результатом выполнения исходного действия, необходим для выполнения
конечного действия.
Связь типа «нечеткое отношение». Связи этого типа используются для выделения отношений между действиями, которые невозможно описать с использованием предшествующих или объектных
связей. Значение каждой такой связи должно быть определено,
поскольку связи типа «нечеткое отношение» сами по себе не предполагают никаких ограничений. Одно из применений нечетких отношений – отображение взаимоотношений между параллельно выполняющимися действиями.
В отличие от диаграмм IDEF0 в диаграммах IDEF3 завершение
одного действия может инициировать начало выполнения сразу нескольких других действий или, наоборот, определенное действие
может требовать завершения нескольких других действий до начала своего выполнения. Соединения разбивают или соединяют внутренние потоки и используются для описания ветвления процесса.
Действия в IDEF3 могут быть разложены на составляющие для
более детального анализа. Метод IDEF3 позволяет декомпозировать действие несколько раз, что обеспечивает документирование
альтернативных потоков процесса в одной модели. Пример IDEF3диаграммы представлен на рис. 5.4.
94
95
Х
17
J15
Х
18
Сверять
расцеховку
Если была необходимость
утверждения у главного
металлурга (документация
проходила через ХМО), то
в J18, иначе в J19
Сверять
материалы и
нормы их расхода
0р
0р
Проверять
в ОГТ
10
Если есть
необходимость
доработки, то
в J14, иначе
в п.18
J18
J17
J19
Х
&
J16
Х
Х
20
Утверждать
у главного
металлурга
0р
19
0р
Утверждать
у главного
технолога
Х
&
J21
J20
Х
J14
Если была необходимость
утверждения у главного
металлурга (документация
проходила через ХМО), то
в J21, иначе в J14
Рис. 5.4. Пример описания процесса утверждения технологической документации
с использованием методологии IDEF3
15
0р
Регистрировать
в журнале ОГТ
Если есть
необходимость
доработки, то
в J14, иначе
в п.17
Если есть
необходимость
доработки, то
в J14, иначе
в J17
DFD (Data Flow Diagrams) – диаграммы потоков данных. Описывают внешние по отношению к системе источники и адресаты
данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ. Как показывает практика, это один из самых простых, доступных и наглядных стандартов
для описания бизнес-процессов.
В основе моделирования в DFD лежит построение модели анализируемой системы – проектируемой или реально существующей.
В соответствии с методологией модель системы определяется как
иерархия диаграмм потоков данных (DFD), описывающих асинхронный процесс преобразования информации от ее ввода в систему до
выдачи пользователю. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается,
создавая многоуровневую иерархию диаграмм, до тех пор, пока не
будет достигнут такой уровень декомпозиции, на котором процессы
становятся элементарными и детализировать их далее невозможно.
Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию
к подсистемам или процессам. Те в свою очередь преобразуют информацию и порождают новые потоки, которые переносят информацию
к другим процессам или подсистемам, накопителям данных или
внешним сущностям – потребителям информации. Таким образом,
основными компонентами диаграмм потоков данных являются:
внешние сущности;
системы/подсистемы;
процессы;
накопители данных;
потоки данных.
Внешняя сущность представляет собой материальный предмет
или физическое лицо, представляющее собой источник или приемник информации, например заказчики, персонал, поставщики,
клиенты, склад. Определение некоторого объекта или системы
в качестве внешней сущности указывает на то, что она находится
за пределами границ анализируемой системы. В процессе анализа
некоторые внешние сущности могут быть перенесены внутрь диаграммы анализируемой ИС, если это необходимо, или, наоборот,
часть процессов ИС может быть вынесена за пределы диаграммы и
представлена как внешняя сущность. Внешняя сущность обозначается квадратом, расположенным как бы «над» диаграммой.
96
При построении модели сложной системы она может быть представлена в самом общем виде на так называемой контекстной диаграмме в виде одной системы как единого целого, либо может быть
декомпозирована на ряд подсистем. Номер подсистемы служит для
ее идентификации. В поле имени вводится наименование подсистемы в виде предложения с подлежащим и соответствующими определениями и дополнениями.
Процесс представляет собой преобразование входных потоков
данных в выходные в соответствии с определенным алгоритмом.
Физически процесс может быть реализован различными способами: это может быть подразделение организации (отдел), выполняющее обработку входных документов и выпуск отчетов, программа,
аппаратно реализованное логическое устройство и т. д.
Номер процесса служит для его идентификации. В поле имени
вводится наименование процесса в виде предложения с активным
недвусмысленным глаголом в неопределенной форме (вычислить,
рассчитать, проверить, определить, создать, получить), за которым
следуют существительные в винительном падеже, например:
«Ввести сведения о проектных процедурах»;
«Выдать информацию о стоимости проектной операции».
Использование таких глаголов, как «обработать», «модернизировать» или «отредактировать» означает, как правило, недостаточно
глубокое понимание данного процесса и требует дальнейшего анализа.
Информация в поле физической реализации показывает, какое
подразделение организации, программа или аппаратное устройство выполняет данный процесс.
Накопитель данных представляет собой абстрактное устройство
для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь, причем способы помещения и извлечения могут быть любыми.
Накопитель данных может быть реализован физически в виде
микрофиши, ящика в картотеке, таблицы в оперативной памяти,
файла на магнитном носителе и т. д. Накопитель данных идентифицируется буквой «D» и произвольным числом. Имя накопителя выбирается из соображения наибольшей информативности для
проектировщика.
Накопитель данных в общем случае является прообразом будущей базы данных, и описание хранящихся в нем данных должно
быть увязано с информационной моделью.
Поток данных определяет информацию, передаваемую через
некоторое соединение от источника к приемнику. Реальный поток
97
данных может быть информацией, передаваемой по кабелю между
двумя устройствами, пересылаемыми по почте письмами, магнитными лентами или дискетами, переносимыми с одного компьютера
на другой и т. д.
Первым шагом при построении иерархии DFD является построение контекстных диаграмм. Обычно при проектировании относительно простых систем строится единственная контекстная диаграмма со звездообразной топологией, в центре которой находится
так называемый главный процесс, соединенный с приемниками и
источниками информации, посредством которых с системой взаимодействуют пользователи и другие внешние системы. На рис. 5.5
приведен пример DFD-диаграммы.
Для сложных систем строится иерархия контекстных диаграмм.
При этом контекстная диаграмма верхнего уровня содержит не
единственный главный процесс, а набор подсистем, соединенных
потоками данных. Контекстные диаграммы следующего уровня детализируют контекст и структуру подсистем.
В настоящее время наблюдается тенденция интеграции разнообразных методов моделирования и анализа систем, проявляющаяся в форме создания интегрированных средств моделирования.
Одним из таких средств является продукт, носящий название
ARIS (Architecture of Integrated Information System) [18], разработанный немецкой фирмой IDS Scheer. Система ARIS представляет
собой комплекс средств анализа и моделирования деятельности
предприятия. Ее методическую основу составляет совокупность
различных методов моделирования, отражающих разные взгляды
на исследуемую систему. Одна и та же модель может разрабатываться с использованием нескольких методов, что позволяет использовать ARIS специалистам с различными теоретическими знаниями и настраивать его на работу с системами, имеющими свою
специфику.
Методика моделирования ARIS основывается на разработанной
профессором Августом Шером теории построения интегрированных информационных систем, определяющей принципы визуального отображения всех аспектов функционирования анализируемых компаний. ARIS поддерживает четыре типа моделей, отражающих различные аспекты исследуемой системы:
организационные модели, представляющие структуру системы – иерархию организационных подразделений, должностей и
конкретных лиц, связи между ними, а также территориальную
привязку структурных подразделений;
98
99
Рис. 5.5. Пример DFD-диаграммы «Отгрузка и снабжение»
функциональные модели, содержащие иерархию целей, стоящих перед аппаратом управления, с совокупностью деревьев функций, необходимых для достижения поставленных целей;
информационные модели, отражающие структуру информации,
необходимой для реализации всей совокупности функций системы;
модели управления, представляющие комплексный взгляд на
реализацию бизнес-процессов в рамках системы.
Для построения перечисленных типов моделей используются
как собственные методы моделирования ARIS, так и различные известные методы и языки моделирования, в частности UML.
UML (Unified Modeling Language) – объектно-ориентированный
графический язык для визуализации, специфицирования, конструирования и документирования систем, где большая роль отводится описанию бизнес-процессов. UML является языком широкого профиля, это открытый стандарт, использующий графические
обозначения для создания абстрактной модели системы, которая
называется UML-моделью. UML-моделирование применяется для
анализа и синтеза подсистем и компонентов САПР. Состав методики: моделирование предметной области; требования к системе; анализ и проектирование; тестирование; запуск.
Диаграммы IDEF0 (см. выше) обладают рядом недостатков.
В частности, они не имеют математической основы. Другой недостаток заключается в отсутствии визуальных средств для объектно-ориентированного представления сложных систем. Метод
IDEF0 в сочетании с другими методами моделирования сложных
систем послужил основой для создания методов объектно-ориентированного моделирования систем и языка UML.
К середине 90-х годов число методов моделирования сложных
систем возросло до более чем 50. В этой связи возникла проблема их
обобщения и унификации. Частично она была решена в результате
создания языка UML.
По определению Гради Буча [19, 20], унифицированный язык моделирования (Unified Modelling Language, UML) является графическим
языком для визуального представления, составления спецификаций,
проектирования и документирования систем, в которых большая
роль принадлежит программному обеспечению. Мы будем называть
такие системы автоматизированными информационными системами (АИС) и полагать, что в работе АИС участвуют люди. С помощью
языка UML можно разработать общесистемную документацию АИС,
документацию ее программного обеспечения и создать многократно
используемые (т. е. типовые) компоненты программного обеспечения.
100
Решающую роль в создании языка UML сыграли Гарди Буч,
Джеймс Рамбо и Айвар Джекобсон и созданные ими следующие
методы моделирования различных сторон сложных систем:
1) метод Буча (Booch›93), ориентированный, в первую очередь,
на моделирование программного обеспечения сложных систем;
2) метод Рамбо (ОМТ-2), ориентированный на анализ процессов
обработки данных в информационных системах;
3) метод Джекобсона (метод OOSE), ориентированный на анализ
требований к бизнес-приложениям.
Авторы этих методов объединились с целью создания унифицированного языка моделирования сложных систем. Они сформулировали следующие требования к унифицированному языку, который был назван UML. Язык UML:
1) позволяет моделировать как программное обеспечение сложных систем, так и широкие классы самих систем и бизнес-приложений, с использованием объектно-ориентированных понятий и
методов;
2) обеспечивает взаимосвязь между базовыми понятиями моделей концептуального, программного и физического уровней;
3) понятен системным аналитикам и программистам;
4) поддерживается специальными инструментальными программными средствами, реализованными на различных компьютерных платформах.
В 1996 году была создана первая версия языка UML 0.9. После
этого ведущие компьютерные фирмы Microsoft, IBM, Oracle и многие другие осознали, что язык UML имеет стратегическое значение
для их бизнеса. В результате был организован консорциум UML,
деятельность которого оплачивается за счет ежегодных денежных
взносов фирм-членов консорциума.
Важную роль в создании языка UML сыграла его поддержка Группой по управлению объектами OMG (Object Management
Group). Группа OMG объединяет около 300 ведущих компьютерных фирм. Она выпускает стандарты в области Интернет/Веб.
Язык UML приобрел статус второго стратегического направления
деятельности OMG. В 1997 году были созданы версии языка UML
1.0 и 1.1. В 1998 году была создана версия UML 1.2, а в 1999 году –
версия UML 1.3. В переводной российской литературе по языку
UML описывается его версия 1.3.
В настоящее время разработаны инструментальные программы
поддержки языка UML. Наиболее известной из них является программа Rational Rose фирмы Rational Software. Кроме того создан
101
ряд средств визуального программирования, обеспечивающий прямую генерацию кода программ из UML-моделей. Эти средства интегрированы с наиболее распространенными языками программирования Java, C++ и многими другими. Группа OMG продолжает
работы по созданию новых версий языка UML.
В распоряжение проектировщика предоставляются следующие
типы диаграмм, последовательное создание которых позволяет получить полное представление о всей проектируемой системе и об отдельных ее компонентах:
Use case diagram (диаграммы прецедентов);
Deployment diagram (диаграммы топологии);
Statechart diagram (диаграммы состояний);
Activity diagram (диаграммы активности);
Interaction diagram (диаграммы взаимодействия);
Sequence diagram (диаграммы последовательностей действий);
Collaboration diagram (диаграммы сотрудничества);
Class diagram (диаграммы классов);
Component diagram (диаграммы компонентов).
Use case diagram (диаграммы прецедентов). Этот вид диаграмм
позволяет создать список операций, которые выполняет система.
Часто этот вид диаграмм называют диаграммой функций, потому
что на основе набора таких диаграмм создается список требований
к системе и определяется множество выполняемых системой функций. Данный тип диаграмм используется при описании бизнес-процессов автоматизируемой предметной области, определении требований к будущей программной системе. Отражает объекты как
системы, так и предметной области и задачи, ими выполняемые.
Deployment diagram (диаграммы топологии). Этот вид диаграмм
предназначен для анализа аппаратной части системы, т. е. «железа», а не программ. В прямом переводе с английского Deployment
означает «развертывание», но термин «топология» точнее отражает сущность этого типа диаграмм.
Для каждой модели создается только одна такая диаграмма,
отображающая процессоры (processor), устройства (device) и их соединения.
Обычно этот тип диаграмм используется в самом начале проектирования системы для анализа аппаратных средств, на которых
она будет эксплуатироваться.
Statechart diagram (диаграммы состояний). Каждый объект системы, обладающий определенным поведением, может находится
в определенных состояниях, переходить из состояния в состояние,
102
совершая определенные действия в процессе реализации сценария
поведения объекта. Поведение большинства объектов реальных
систем можно представить с точки зрения теории конечных автоматов, т. е. поведение объекта отражается в его состояниях, и данный тип диаграмм позволяет отразить это графически. Для этого
используется два вида диаграмм: Statechart diagram (диаграмма
состояний) и Activity diagram (диаграмма активности).
Диаграмма состояний (Statechart) предназначена для отображения состояний объектов системы, имеющих сложную модель поведения. Это одна из двух диаграмм State Machine, доступ к которой
осуществляется из одного пункта меню.
Activity diagram (диаграмма активности). Это дальнейшее развитие диаграммы состояний. Фактически данный тип диаграмм
может использоваться и для отражения состояний моделируемого
объекта, однако основное назначение Activity diagram в том, чтобы
отражать бизнес-процессы объекта. Этот тип диаграмм позволяет
показать не только последовательность процессов, но и ветвление и
даже синхронизацию процессов.
Этот тип диаграмм позволяет проектировать алгоритмы поведения объектов любой сложности, в том числе может использоваться
для составления блок-схем.
Interaction diagram (диаграммы взаимодействия). Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы
последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.
Sequence diagram (диаграммы последовательностей действий).
Взаимодействие объектов в системе происходит посредством приема и передачи сообщений объектами-клиентами и обработки этих
сообщений объектами-серверами. При этом в разных ситуациях
одни и те же объекты могут выступать и в качестве клиентов, и
в качестве серверов.
Данный тип диаграмм позволяет отразить последовательность
передачи сообщений между объектами.
Этот тип диаграммы не акцентирует внимание на конкретном
взаимодействии, главный акцент уделяется последовательности
приема/передачи сообщений. Для того чтобы окинуть взглядом все
взаимосвязи объектов, служит Collaboration diagram.
Collaboration diagram (диаграммы сотрудничества). Этот тип
диаграмм позволяет описать взаимодействия объектов, абстрагируясь от последовательности передачи сообщений. На этом типе
103
диаграмм в компактном виде отражаются все принимаемые и передаваемые сообщения конкретного объекта и типы этих сообщений.
Class diagram (диаграммы классов). Этот тип диаграмм позволяет создавать логическое представление системы, на основе которого
создается исходный код описанных классов.
/Начать
Начало
/ Зарегистрировать
Указание на согласование
/ Вернуть
/ Вернуть
/На рассмотрение
/ Завершить
/ Прекратить
Рассмотрение
Завершено
Прекращено
/ На обработку
/Завершить
/Прекратить
/Вернуть на обработку
Обработка
/ Отложить
/ На обработку
Отложено
Рис. 5. 6. Пример Activity diagram «Утверждение документа»
104
Летательный аппарат
Бортовой номер
Максимальная скорость
Сменить место приписки
Аэроплан
Вертолет
Размах крыльев
Диаметр винта
Мощность двигателя
Самолет
Планер
Мощность двигателя
Грузоподъемность
Рис. 5. 7. Пример Class diagram «Летательные аппараты»
Значки диаграммы позволяют отображать сложную иерархию
систем, взаимосвязи классов (Classes) и интерфейсов (Interfaces).
Component diagram (диаграммы компонентов). Этот тип диаграмм предназначен для распределения классов и объектов по компонентам при физическом проектировании системы. Часто данный
тип диаграмм называют диаграммами модулей.
При проектировании больших систем может оказаться, что система должна быть разложена на несколько сотен или даже тысяч
компонентов, и этот тип диаграмм позволяет не потеряться в обилии модулей и их связей. На рис. 5.6 и 5.7 показаны примеры
UML-диаграмм Activity diagram (диаграммы активности) и Class
diagram (диаграммы классов).
Контрольные вопросы
1. Какие задачи решаются с помощью программ управления
проектами?
2. Какой смысл носит построение моделей AS-IS и ТО-ВЕ в нотации IDEF0?
3. Какие типы связей используются в диаграммах IDEF3?
105
4. Какая из двух типов диаграмм IDEF0 или IDEF3 дает возможность разветвления, слияния или ветвления процессов?
5. Перечислите основные компоненты диаграмм потоков данных DFD.
6. Какие из UML-диаграмм могут применяться для отображения состояний объектов системы, имеющих сложную модель поведения?
Заключение
В предлагаемом учебном пособии представлен только тот материал, который позволяет выявить основы сложного процесса внедрения САПР как основной составляющей информационных технологий в промышленности. Анализ и взаимосвязь САПР со всеми
составляющими ИНТЕХ от идеи создания будущего изделия до его
эксплуатации позволили сделать эту книгу в равной степени полезной для студентов, обучающихся по направлениям «Информатика
и вычислительная техника», «Системный анализ управление»,
а также широкому кругу студентов и специалистов, связанных
с проектированием, производством и эксплуатацией промышленных изделий.
106
Библиографический список
1. Сольницев Р. И. Автоматизация проектирования систем автоматического управления: учеб. пособие. М.: Высш. шк., 1991. 315 с.
2. Сольницев Р. И., Цуканов В. Н., Шишкин Б. М. Методическое
и организационное обеспечение САПР: учеб. пособие. СПб.: ГААП,
1992. 80 с.
3. Сольницев Р. И. Информационные технологии в проектировании: учеб. пособие для вузов. СПб.: ГУАП, 2007. 60 с.
4. Норенков И. П. Основы автоматизированного проектирования: учеб. для вузов. М.: МГТУ им. Н. Э. Баумана, 2009. 430 с.
5. Кунву Ли. Основы САПР (CAD/CAM/CAE); пер. с англ. СПб.:
Питер, 2004. 560 с.
6. Быков В. П. Методическое обеспечение САПР в машиностроении. Л.: Машиностроение, 1989. 255 с.
7. Основания технологии комплементарного проектирования
наукоемких изделий: монография / И. В. Герасимов, С. А. Кузьмин, Л. Н. Лозовой, А. В. Никитин. СПб.: Изд-во СПбГЭТУ
«ЛЭТИ», 2010. 206 с.
8. Колчков В. И. Метрология, стандартизация и сертификация:
учеб. пособие. М.: Владос, 2010. 400 с.
9. Орлов И. И., Маслов С. И. Системы автоматизированного проектирования электромеханических устройств. М.: Энергоатомиздат, 1989. 296 с.
10. Малеев Е. И., Парфенов Е. М., Соловьев А. С. Организационное обеспечение автоматизированного конструирования радиоэлектронной аппаратуры. М.: Радио и связь, 1985. 136 с.
11. Кастеллани К. Автоматизация решения задач управления;
пер. с франц. М.: Мир, 1982. 256 с.
12. http://www.iso.org/ – официальный сайт международной
организация по стандартизации ISO.
13. Норенков И. П., Кузьмик П. К. Информационная поддержка наукоемких изделий CALS-технологии. М.: Изд-во МГТУ им.
Н. Э. Баумана, 2002. 320 с.
14. Андронов С. А., Пиль Э. А. Системы управления проектами:
MS Project 2002: учеб. пособие. СПб.: ГААП, 2007. 138 с.
15. Перевощиков Ю. С. Управление проектами в машиностроении: учеб. пособие. М.: ИНФРА, 2010. 233 с.
16. Черемных С. В., Семенов И. О., Ручкин В. С. Моделирование
и анализ систем. IDEF-технологии: практикум. М.: Финансы и статистика, 2006. 192 с.
107
17. Маклаков С. В. Моделирование бизнес-процессов. М.: Диалог Мифи, 2002. 224 с.
18. Август-Вильгельм Шеер. ARIS-моделирование бизнес-процессов. М.: Весть-МетаТехнология, 2000. 175 с.
19. Гради Буч, Джеймс Рамбо, Ивар Якобсон. Введение в UML
от создателей языка. М.: ДМК-Пресс, 2011. 496 с.
20. Леоненков А. Самоучитель UML: монография. СПб.: БХВПетербург, 2001. 298 с.
108
ОГЛАВЛЕНИЕ
Введение ..........................................................................
1. Основные определения и понятия ....................................
1.1. Назначение и построение САПР ................................
1.2. Процесс проектирования и принципы
его автоматизации ........................................................
Контрольные вопросы........................................................
2. Обследование предприятия до внедрения САПР .................
2.1. Обследование проектно-производственного
предприятия ................................................................
2.2. Обследование эксплуатационно-дистрибьюторского
предприятия ................................................................
Контрольные вопросы........................................................
3. Стандартизация при внедрении САПР ..............................
3.1. Стандарты в области проектирования и производства ..
3.2. Стандарты обмена графической информацией.............
3.3. Принципы построения международных стандартов .....
Контрольные вопросы........................................................
4. Интеграция САПР в обобщенные информационные
технологии.......................................................................
4.1. Развитие интеграционных процессов .........................
4.2. Место САПР в CALS-технологиях..............................
4.3. Унификация форм документации на изделие
в едином информационном пространстве ..........................
Контрольные вопросы........................................................
5. Применение информационных технологий организации
и управления при внедрении САПР .....................................
5.1. Применение информационных технологий
управления проектами ..................................................
5.2. Функциональное моделирование процессов
автоматизированного проектирования .............................
Контрольные вопросы........................................................
Заключение .....................................................................
Библиографический список ................................................
3
5
5
14
19
20
20
36
56
57
57
60
65
71
73
73
78
83
85
86
86
89
105
106
107
109
Учебное издание
Сольницев Ремир Иосифович,
Гришанова Лариса Иосифовна
ВНЕДРЕНИЕ СИСТЕМ АВТОМАТИЗАЦИИ
ПРОЕКТИРОВАНИЯ
Учебное пособие
Редактор А. В. Подчепаева
Компьютерная верстка С. Б. Мацапуры
Сдано в набор 13.12.14. Подписано к печати 30.12.14.
Формат 6084 1/16. Бумага офсетная. Усл. печ. л. 6,5.
Уч.-изд. л. 7,0. Тираж 100 экз. Заказ № 695.
Редакционно-издательский центр ГУАП
190000, Санкт-Петербург, Б. Морская ул., 67
Документ
Категория
Без категории
Просмотров
2
Размер файла
399 Кб
Теги
solnicev
1/--страниц
Пожаловаться на содержимое документа