close

Вход

Забыли?

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

?

2609.Автоматизация управления жизненным циклом электротехнической продук.

код для вставкиСкачать
Федеральное агентство по образованию
Государственное образовательное учреждение
высшего профессионального образования
«Пермский государственный технический университет»
С. В. Бочкарев, А. Б. Петроченков, А. В. Ромодин
АВТОМАТИЗАЦИЯ УПРАВЛЕНИЯ ЖИЗНЕННЫМ
ЦИКЛОМ ЭЛЕКТРОТЕХНИЧЕСКОЙ ПРОДУКЦИИ
Утверждено Редакционно-издательским советом
университета в качестве учебного пособия
Издательство
Пермского государственного технического университета
2008
УДК 658.012:004.42(075.8)
Б86
Рецензенты:
генеральный директор научно-исследовательского института
управляющих машин и систем доктор технических наук, профессор,
лауреат Государственной премии России, премии Правительства России,
премии Ленинского комсомола
В. Н. Аликин;
заведующий кафедрой информационных технологий
и автоматизированных систем доктор экономических наук, профессор
Р. А. Файзрахманов
(Пермский государственный технический университет)
Б86
Бочкарев, С.В.
Автоматизация управления жизненным циклом электротехнической
продукции: учеб. пособие / С. В. Бочкарев, А. В. Петроченков, А. В. Ромодин. – Пермь: Изд-во Перм. гос. техн. ун-та, 2008. – 365 с.
ISBN 978-5-88151-953-1
Рассматриваются теоретические основы совершенствования деятельности предприятий на основе CALS-технологий. Анализируется жизненный цикл продукции;
выявляются процессы, входящие в его состав. Разбираются вопросы, связанные с организацией единого информационного пространства, интегрированной логистической
поддержки. Приведен пример разработки информационно-аналитической среды поддержки жизненного цикла электротехнического оборудования.
Предназначено для студентов технических вузов, аспирантов и преподавателей.
УДК 658.012:004.42(075.8)
Издано в рамках приоритетного национального проекта «Образовние» по программе Пермского государственного технического университета «Создание инновационной системы формирования профессиональных компетенций кадров и центра
инновационного развития региона на базе многопрофильного технического университета».
ISBN 978-5-88151-953-1
© ГОУ ВПО «Пермский государственный
технический университет», 2008
ОГЛАВЛЕНИЕ
Введение ......................................................................................................................................... 7
1. ОБЩИЙ ОБЗОР CALS-ТЕХНОЛОГИЙ ............................................................................... 9
1.1. Понятие о CALS-технологиях ................................................................................. 9
1.2. CALS – коммерчески выгодная стратегия............................................................ 18
1.3. Примеры реализации CALS за рубежом .............................................................. 22
1.4. Стратегия формирования и развития CALS-технологий
в промышленности России ................................................................................... 28
1.5. Мероприятия Минпромнауки по внедрению ИПИ-технологий ......................... 29
1.6. Межведомственная программа развития и внедрения ИПИ-технологий ......... 30
1.7. Технико-экономические преимущества ИПИ-технологий ................................. 32
1.8. Стратегия развития предприятий.......................................................................... 33
1.9. Контрольные вопросы............................................................................................ 37
2. РАЗРАБОТКА ИПИ-ТЕХНОЛОГИЙ................................................................................... 38
2.1. Продукт и его жизненный цикл ............................................................................ 38
2.2. Концепция CALS.................................................................................................... 47
2.3. Концептуальная модель CALS (ИПИ) .................................................................. 48
2.4. Интегрированная информационная среда предприятия...................................... 51
2.4.1. Общее понятие о ИИС ........................................................................................... 51
2.4.2. Структура и состав ИИС........................................................................................ 53
2.4.3. Управление ИИС .................................................................................................... 58
2.5. Создание единого информационного пространства (ЕИП) ................................ 60
2.5.1. Виртуальные предприятия..................................................................................... 60
2.5.2. Основные проблемы при управлении информацией ........................................... 63
2.6. Единое информационное пространство................................................................ 65
2.7. Контрольные вопросы............................................................................................ 70
3. СТАНДАРТЫ CALS ............................................................................................................... 71
3.1. STEP-стандарт для описания данных об изделии................................................ 72
3.1.1. Методы описания ................................................................................................... 75
3.1.2. Методы реализации................................................................................................ 76
3.2. Технологии представления данных и информационные модели
по ИСО 10303 (STEP) ........................................................................................... 77
3.3. Проектные данные об изделии .............................................................................. 81
3.4. Структура моделей на языке Express.................................................................... 90
3.4.1. Типы данных в языке Express................................................................................ 91
3.4.2. Язык Express: супертипы и подтипы .................................................................... 95
3.4.3. Язык Express: ограничения .................................................................................... 97
3.4.4. Язык Express: процедуры и функции.................................................................... 98
3
3.4.5. Express-X ...............................................................................................................100
3.4.6. Расширения языка Express ...................................................................................101
3.4.7. Примеры моделей на языке Express ....................................................................102
3.5. Зарубежные стандарты.........................................................................................104
3.6. Стандарты России.................................................................................................115
3.7. Совместное использование стандартов...............................................................122
3.8. Контрольные вопросы ..........................................................................................123
4. ИНФОРМАЦИОННАЯ ИНТЕГРАЦИЯ ПРОЦЕССОВ
ЖИЗНЕННОГО ЦИКЛА ИЗДЕЛИЯ...................................................................................... 124
4.1. Система управления данными об изделии PDM ................................................128
4.2. Интеграция данных ..............................................................................................138
4.3. Управление конфигурацией.................................................................................146
4.3.1. Контексты управления конфигурацией ..............................................................154
4.3.2. Информационные аспекты управления конфигурацией....................................158
4.3.3. Сценарии управления конфигурацией ................................................................164
4.3.4. Теоретические аспекты проблемы управления конфигурацией .......................167
4.3.5. Методика синтеза конфигураций ........................................................................174
4.4. Особенности системы управления проектами....................................................176
4.5. Контрольные вопросы ..........................................................................................183
5. ИНТЕГРИРОВАННАЯ ЛОГИСТИЧЕСКАЯ ПОДДЕРЖКА ......................................... 184
5.1. Актуальность проблемы повышения качества продукции ................................184
5.2. Стандарты управления качеством .......................................................................186
5.2.1. Международные стандарты .................................................................................187
5.2.2. Стандарты ИСО 9000 в российской сертификации............................................190
5.3. Постановка целей и задач системы управления качеством ...............................192
5.4. Реализация информационной поддержки систем менеджмента качества.......193
5.5. ИЛП как метод оптимизации стоимости ЖЦ изделия .......................................195
5.6. Логистический анализ ..........................................................................................201
5.7. Группы задач логистического анализа................................................................204
5.8. Пригодность к поддержке ....................................................................................209
5.9. Выбор задач логистического анализа для конкретного проекта.......................210
5.10. Интегрированные процедуры поддержки материально-технического
обеспечения...........................................................................................................213
5.11. Регламент технического обслуживания и ремонта изделия ...............................217
5.12. Представление процедурно-технологической информации...............................220
5.13. Представление данных о возможных неисправностях .......................................223
5.14. Сравнительный анализ технологий представления данных ...............................224
5.15. Информационное обеспечение ИЛП и формирование единой
информационной модели изделия ........................................................................227
5.16. Контрольные вопросы ...........................................................................................230
4
6. ЭЛЕКТРОННЫЙ ДОКУМЕНТООБОРОТ ....................................................................... 231
6.1. Электронный технический документ.................................................................. 231
6.2. Система автоматизации документооборота ....................................................... 234
6.3. Электронная цифровая подпись .......................................................................... 237
6.4. Структурирование информации в ЭТД .............................................................. 239
6.5. Жизненный цикл ЭТД.......................................................................................... 242
6.6. Основные принципы организации канцелярской работы ................................. 245
6.7. Типы документов, классификация и их взаимосвязи ........................................ 246
6.8. Общие атрибуты документов .............................................................................. 248
6.9. Атрибуты, зависящие от типов документа......................................................... 248
6.10. Взаимосвязи документов ...................................................................................... 249
6.11. Типовые процессы канцелярии ............................................................................ 250
6.12. Методы связей с внешним миром ........................................................................ 252
6.13. Оценки объемов документооборота .................................................................... 252
6.14. Отчетность канцелярии о проделанной работе................................................... 253
6.15. Канцелярия и архив предприятия ........................................................................ 255
6.16. Канцелярия и документооборот уровня отдела .................................................. 256
6.17. Канцелярия и специализированное делопроизводство ...................................... 256
6.18. Методы и средства автоматизации учрежденческой деятельности ................. 257
6.19. Методы автоматизации учреждений.................................................................... 257
6.20. Средства автоматизации учреждений и коллективной работы в сетях............ 261
6.21. Средства управления электронными документами ............................................ 263
6.22. Средства автоматизации документооборота ....................................................... 265
6.23. Контрольные вопросы........................................................................................... 269
7. ИНТЕРАКТИВНОЕ ЭЛЕКТРОННОЕ ТЕХНИЧЕСКОЕ РУКОВОДСТВО ................ 270
7.1. Создание эксплуатационной документации....................................................... 270
7.2. Принципы создания и применения ИЭТР .......................................................... 273
7.3. Компоненты ИЭТР ............................................................................................... 274
7.4. Классификация интерактивных электронных технических руководств ......... 275
7.6. Контрольные вопросы.......................................................................................... 282
8. АВТОМАТИЗАЦИЯ УПРАВЛЕНИЯ ЖИЗНЕННЫМ ЦИКЛОМ
ЭЛЕКТРОТЕХНИЧЕСКОГО ОБОРУДОВАНИЯ ............................................................... 283
8.1. Обзор видов обслуживания электротехнического оборудования .................... 283
8.2. Выбор подхода к организации технической диагностики ................................ 286
8.2.1. Основные понятия и определения технической диагностики .......................... 286
8.2.2. Методология технической диагностики ............................................................. 288
8.2.3. Диагностирование в жизненном цикле электрооборудования ......................... 290
8.2.4. Характеристика методов диагностирования элементов ЭУ.............................. 292
8.3. Прогнозирование технического состояния электрооборудования ................... 294
5
8.3.1. Характеристика задачи прогнозирования ...........................................................294
8.3.2. Аналитическое прогнозирование ........................................................................297
8.3.3. Вероятностное прогнозирование.........................................................................303
8.3.4. Прогнозирование методами статистической классификации ..........................305
8.4. Уровни адекватности оценок использования информации о техническом
состоянии элементов системы электроснабжения предприятия......................307
8.5. Обзор современных автоматизированных систем технической диагностики,
используемых на предприятиях нефтегазовой отрасли....................................311
8.5.1. Система мониторинга и диагностики вращающегося оборудования по
вибрации с пакетом программ DREAM for Windows .........................................311
8.5.2. Система «Aurora-2000» ........................................................................................313
8.5.3. Автоматизированный комплекс для диагностики функционального состояния
электрических машин.............................................................................................315
8.6. Разработка информационно-аналитической среды поддержки жизненного
цикла электротехнического оборудования ..........................................................318
8.6.1. Общие сведения о системе...................................................................................318
8.6.2. Структура системы ...............................................................................................318
8.6.3. Интерфейс ПК.......................................................................................................334
8.6.5. Работа со справочниками .....................................................................................338
8.7. Связь с корпоративными системами, развернутыми на предприятии.............348
8.8. Отчетные формы...................................................................................................349
8.9. Контрольные вопросы ..........................................................................................351
Приложение. Язык Express (примеры)..........................................................................353
Список рекомендуемой литературы..............................................................................363
6
ВВЕДЕНИЕ
В настоящее время на мировом рынке наукоемких промышленных изделий
(самолетов, кораблей, автомобилей, военной техники, электротехнической продукции и т. п.) наблюдаются три основные тенденции:
• повышение сложности и ресурсоемкости изделий. Промышленные изделия
становятся все более сложными по своей структуре, усложняются технологии их
изготовления. Например, количество деталей в современном грузовом самолете
составляет несколько миллионов штук. Усложнение изделий приводит к повышению потребностей в ресурсах, необходимых для их разработки, производства
и эксплуатации. Так, стоимость одного истребителя пятого поколения F-22 Raptor
составляет 83,6 миллиона долларов, а его разработка обходится намного дороже;
• повышение конкуренции на рынке. Одновременно с увеличением сложности
изделий увеличивается конкуренция между их производителями за возможность
продать их потребителю. Залогом успеха для производителя становится максимально полное удовлетворение потребностей потребителя, а также максимально
возможное сокращение затрат при разработке, производстве и эксплуатации
изделия;
• углубление кооперации между участниками жизненного цикла (ЖЦ) изделия. Для разработки и продвижения на рынок промышленных изделий все шире
применяются так называемые «виртуальные предприятия» (ВП).
Из трех указанных тенденций следует выделить усиление конкуренции на мировых рынках, которая ставит перед промышленниками и предпринимателями
в качестве основной задачи экономию ресурсов (материальных, интеллектуальных,
информационных и временных), привлекаемых для реализации конкретного проекта или программы на всех стадиях ЖЦ изделий: от разработки и производства
до модернизации и утилизации. Это предполагает также ускорение действий
и создание условий для более тесной кооперации производителей.
Особую роль в решении этой группы проблем сыграли и продолжают играть
информационные технологии (ИТ). В современных условиях ИНФОРМАЦИЯ стала ОСНОВНЫМ ТОВАРОМ.
Производство сложных машинотехнических изделий сегодня немыслимо
без обеспечения их информационной поддержки на всех стадиях ЖЦ. Информационная поддержка – это целый комплекс вопросов, включающий автоматизацию
процессов проектирования, обеспечение технологических процессов производства,
автоматизацию управленческой деятельности предприятий, создание электронной
эксплуатационной документации, внедрение автоматизированных систем заказа
запасных частей и т. д.
Ситуация на мировом рынке наукоемкой продукции развивается в сторону
полного перехода на безбумажную электронную технологию ее проектирования,
изготовления и сбыта. По прогнозам зарубежных специалистов, после 2007 г. невозможно будет продать на внешнем рынке машинотехническую продукцию
без соответствующей международным стандартам безбумажной электронной документации. Передовые зарубежные фирмы рассматривают работу в этом
7
направлении как действенное средство ограничения доступа на международный
рынок наукоемкой продукции тех стран, которые не сумеют своевременно освоить соответствующую международным требованиям безбумажную электронную технологию.
Если брать за основу японский пример организации системы качества
и управления ею, то можно выделить целостный управленческий подход к достижению долговременного успеха. Понятие «целостный управленческий подход»
предполагает опору на «трех китов» современного бизнеса: качество, сроки и цену.
Именно эти показатели имеют определяющее значение в конкурентной борьбе
для продукции любого современного предприятия.
Стало ясно, что устоять в конкурентной борьбе смогут только те предприятия,
которые будут применять в своей деятельности современные информационные
технологии. Именно ИТ наряду с прогрессивными технологиями материального
производства позволяют существенно повысить производительность труда и качество выпускаемой продукции при значительном сокращении сроков постановки
на производство изделий, отвечающих запросам и ожиданиям потребителей.
В настоящее время конкуренция между государствами сводится в основном
к соперничеству за природные ресурсы и высококвалифицированные кадры. Это
объясняется тем, что резервы высоких темпов развития машиностроительных технологий во всем мире оказались практически исчерпанными. Однако известно, что
информационные ресурсы любой развитой страны по стоимости соизмеримы,
а возможно, и превосходят природные ресурсы. Поэтому рост эффективности производства и дальнейший подъем экономики страны возможны только за счет использования современных информационных технологий и при наличии квалифицированных кадров.
В этой связи следует отметить, что в странах НАТО информационные технологии поддержки жизненного цикла изделий оборонно-промышленного комплекса
(ОПК) определяются как «… совместная стратегия государства и промышленности, направленная на совершенствование существующих процессов в промышленности путем их преобразования в информационно-интегрированную систему
управления жизненным циклом изделий».
8
1. ОБЩИЙ ОБЗОР CALS-ТЕХНОЛОГИЙ
1.1. ПОНЯТИЕ О CALS-ТЕХНОЛОГИЯХ
Анализируя работу промышленных предприятий, можно отметить, что, несмотря на разнообразие производственных процессов разных предприятий, они
работают по единой циклической экономико-технологической схеме:
• анализ спроса на продукцию, формирование портфеля договоров, заказов и пр.;
• планирование производства и его ресурсов;
• подготовка производства, разработка новых или модификация текущих изделий;
• снабженческая деятельность, обеспечение процесса основного производства;
• производство изделий и услуг;
• реализация продукции и расчеты с заказчиками;
• государственная отчетность;
• анализ производственного цикла, определение реальной себестоимости;
• управление сервисным обслуживанием;
• распределение прибыли, возврат кредитов и займов;
• вложение средств в следующий производственный цикл.
Все более жесткая конкуренция на международном рынке ставила и ставит
перед промышленниками и предпринимателями различных стран новые проблемы.
К их числу относятся:
• проблема критичности времени, требующегося для создания изделия и организации его продажи;
• проблема повышения качества процессов проектирования и производства;
• проблемы, связанные с конкуренцией на рынке эксплуатационного обслуживания;
• проблемы, связанные с непосредственным снижением затрат (прямые капитальные; оплата труда в производстве, в подразделениях логистики и т. д.).
Практика показала, что частичная, фрагментарная компьютеризация отдельных видов производственной деятельности, будучи делом дорогостоящим,
не оправдывает возлагаемых на нее надежд. Это связано с тем, что первые реализации ИТ представляли собой попытки внедрения качественно новых средств
в традиционную технологическую среду. Эти попытки либо полностью отторгались, либо адаптировались к этой среде таким образом, что эффект от их использования был невелик. Примерами таких попыток могут служить:
• многочисленные АСУ, роль которых сводилась к автоматизации простейших учетных и отчетных функций;
• конструкторские САПР (CAD – Computer Aided Design), заменявшие чертежную доску и кульман экраном дисплея, – автоматизированное проектирование.
Термин используется для обозначения широкого спектра компьютерных инструментов, которые помогают инженерам, архитекторам и другим профессионалам
в осуществлении проектирования. Являясь ключевым инструментом в рамках
9
концепции управления жизненным циклом изделия, системы автоматизированного
проектирования (САПР) включают в себя множество программных и аппаратных
средств – от систем двумерного черчения до трехмерного параметрического моделирования поверхностей и объемных тел. По областям применения САПР традиционно разделяются на:
– архитектурно-строительные;
– механические (см. MCAD);
– электронные (см. ECAD);
– технологические (см. CAPP);
• технологические САПР (САМ – Computer Aided Manufacturing), облегчавшие подготовку технологической документации и управляющих программ для
станков с ЧПУ, – автоматизированное производство. Термин используется для
обозначения программного обеспечения, основной целью которого является создание программ для управления станками с ЧПУ (см. CNC). Входными данными
CAM-системы является геометрическая модель изделия, разработанная в системе
автоматизированного проектирования (см. CAD). В процессе интерактивной работы с трехмерной моделью в CAM-системе инженер определяет траектории движения режущего инструмента по заготовке изделия (так называемые CL-данные, от
cutter location–положение резца), которые затем автоматически верифицируются,
визуализируются (для визуальной проверки корректности) и обрабатываются
постпроцессором для получения программы управления конкретным станком (называемой также G-кодом);
• автоматизация механического проектирования (MCAD – Mechanical CAD).
Механические САПР (см. CAD) отличаются от прочих своими областями применения, которые включают в себя:
– автомобильную промышленность;
– авиакосмическую промышленность;
– производство товаров народного потребления;
– машиностроение;
– судостроение.
Типичная функциональность механических САПР включает в себя разработку
деталей и сборок (механизмов) с использованием параметрического проектирования на основе конструктивных элементов, технологий поверхностного и объемного моделирования. Трехмерные модели и их двумерные чертежи, разработанные
с помощью механических САПР, используются затем в системах технологической
подготовки производства (см. CAPP), программирования станков с ЧПУ (см. CAM
и CNC), быстрого прототипирования (см. Rapid Prototyping), визуализации;
• быстрое прототипирование (RP – Rapid Prototyping). Метод производства
физической модели (прототипа) изделия непосредственно по CAD-данным,
без использования станков с ЧПУ (см. CNC). Наиболее распространенными процессами быстрого прототипирования являются стереолитография, трехмерная печать и ламинирование (LOM – Laminated Object Manugacturing);
• автоматизированные системы инженерных расчетов (САЕ – Computer Aided
Engineering) – автоматизированное конструирование. Использование специального
10
программного обеспечения для проведения инженерного анализа прочности и других технических характеристик компонентов и сборок, выполненных в системах
автоматизированного проектирования (см. CAD). Программы автоматизированного конструирования позволяют осуществлять динамическое моделирование, проверку и оптимизацию изделий и средств их производства. Традиционные области
анализа включают в себя:
– анализ напряжений деталей и сборок методом конечных элементов;
– анализ тепловых и жидкостных потоков методами вычислительной гидродинамики;
– анализ кинематики;
– моделирование динамических механических взаимодействий;
– моделирование производственных операций (литье, прессование и проч.).
При проведении любого вида анализа в системах CAE традиционно выделяются три этапа:
– предварительная обработка данных (построение по геометрической модели
изделия – CAD-данным – требуемой модели исследуемого процесса, например
сетки конечных элементов, точек приложения сил и их векторов);
– анализ модели;
– заключительная обработка результатов (визуализация результатов расчетов
математической модели);
• цифровой макет (DMU – Digital Mock-Up) – виртуальная технология определения модели реального продукта, состоящая из коллекции трехмерных геометрических моделей (взятых из базы данных), размещенных в пространстве в соответствии с представлением о форме продукта, с каждой из которых связана ведомость материалов (см. BOM). Визуализация трехмерного цифрового макета
позволяет инженерам анализировать большие сложные изделия на предмет удобства сборки их компонентов и последующего технического обслуживания;
• технологические САПР (CAPP – Computer-Aided Process Planning) – автоматизированная технологическая подготовка производства (планирование технологических процессов). Используется для обозначения программных инструментов,
применяемых на стыке систем автоматизированного проектирования (см. CAD)
и производства (см. CAM). Задача технологической подготовки – по заданной
CAD-модели изделия составить план его производства, называемый маршрутной
картой. Данный план содержит указания о последовательности технологических
и сборочных операций, используемых станках и проч. Технологическая подготовка
производства всегда осуществляется по имеющейся базе данных типовых технологических процессов, применяемых на конкретном предприятии. Различают два
подхода к автоматизированной технологической подготовке – модифицированный
(вариантный) и генеративный. При модифицированном подходе задача CAPPсистемы состоит в поиске наиболее похожего изделия в существующей базе данных и предъявлению его операционной карты для модификации. При модифицированном подходе широко применяется групповая технология, позволяющая проводить классификации деталей в семейства похожих. Генеративный подход состоит в распознавании у детали типовых конструктивных элементов и применении
11
к ним типовых технологических процессов (токарная обработка, сверление
и проч.). При генеративном подходе используются известные методы искусственного интеллекта для распознавания элементов и логического вывода;
• компьютеризированное числовое программное управление (ЧПУ) (CNC –
Computerized Numerical Control). Используется для управления современными
станками с ЧПУ посредством их программирования с помощью G-кода (стандарт
EIA-274-D). Области его применения следующие: сверление, токарная обработка,
фрезерная обработка, шлифование, газовая резка, операции с листовым металлом.
Подготовка программ для станков с компьютеризированным ЧПУ осуществляется
с помощью систем автоматизированного производства (см. CAM);
• распределенное числовое программное управление (DNC – Distributed
Numerical Control). Современная концепция управления станками с компьютеризированным ЧПУ (см. CNC), состоящая в том, что все станки управляются с центрального компьютера, который загружает в них программы обработки. Распределенное ЧПУ позволяет управлять всем цехом с одного рабочего места;
• коллективная разработка изделия, бизнес-стратегия, рабочий процесс и набор программного обеспечения, которые способствуют совместной работе различных организаций над одним изделием (CPD – Collaborative Product Development).
Коллективная разработка изделия является частью общей концепции управления
его жизненным циклом и состоит из:
– управления данными об изделии (см. PDM);
– визуализации изделия;
– средств организации телеконференций;
– средств трансляции CAD-данных;
• автоматизированное проектирование электронных приборов и устройств
(EDA – Electronic Design Automation). Категория программных инструментов для
проектирования и производства электронных систем – от печатных плат до интегральных микросхем. Данная категория также часто обозначается как ECAD –
САПР электроники, являясь разновидностью автоматизированного проектирования (см. CAD). Термин EDA зачастую используется для обозначения систем автоматизированного конструирования (см. CAE) и производства (см. CAM) в области
электроники;
• САПР электроники (ECAD – Electronic CAD). То же, что автоматизированное проектирование электронных приборов и устройств (см. EDA).
Таким образом, разработка и внедрение в 1970-е гг. CAD/CAM/ CAE-систем
позволили увеличить количество вариантов проектирования и одновременно повысить качество результатов математического моделирования, но это лишь частично решило задачи, непосредственно связанные с проблемами повышения качества процессов проектирования. Дело в том, что все эти средства создавались
на различных вычислительных платформах, в различных языковых средах и, как
правило, были несовместимы между собой, что предопределяло их автономное
использование с необходимостью многократной перекодировки подчас одной
12
и той же информации для ввода ее в ту или иную систему. Помимо резкого возрастания объемов рутинного труда, это приводило к многочисленным ошибкам и, как
следствие, к снижению эффективности систем.
Вместе с тем опыт, накапливавшийся в процессе создания и разработки автономных систем, оказался полезным: он позволил осознать необходимость интеграции систем, реализующих различные ИТ, в единый комплекс, который в отечественной технической литературе получил название ИАСУ – (интегрированная автоматизированная система управления), а в англоязычной литературе – CIM
(Computer Integrated Manufacturing) – комплексно-автоматизированное производство. В настоящее время вместо этого термина используется эквивалентное понятие управления производственными процессами (см. MPM), являющееся ключевой
частью концепции управления жизненным циклом изделия.
1990-е гг. стали годами стремления к объединению информационных технологий, а именно к совместному использованию информации и к созданию виртуальных предприятий. Овладение механизмами реализации этих принципов позволят тем предпринимателям и промышленникам, которые окажутся впереди в этом
вопросе, выстоять в жесткой конкуренции на международном рынке за счет ускорения решения проблем, поставленных перед ними.
Первоначально появление и внедрение ИАСУ (CIM) однозначно связывалось
с высокоавтоматизированными производственными комплексами типа гибких автоматизированных производств и даже полностью автоматизированных предприятий. Однако дальнейшее развитие показало целесообразность внедрения ИАСУ
на предприятиях с умеренным уровнем автоматизации технологических процессов. Существенным оказалось создание в рамках предприятия единого информационного пространства (ЕИП) или интегрированной информационной среды (ИИС),
охватывающей все этапы жизненного цикла (ЖЦ) выпускаемой этим предприятием продукции.
Именно идея ИИС и информационной интеграции стадий ЖЦ стала базовой
при выработке подхода, получившего в США название CALS (Continuous
Acquisition and Life Cycle Support – непрерывная информационная поддержка поставок и жизненного цикла). Отличие этого подхода от АСУ, ИАСУ и др. заключается, прежде всего, в широте охвата. Это видно из определения НАТО:
«…стратегия последовательного преобразования существующих бизнес-процессов
в единый компьютеризированный и информационно-интегрированный процесс
управления жизненным циклом систем военного назначения» (NATO CALS Handbook-2000).
Речь идет не только об управлении производством, а об управлении в ходе
всего ЖЦ. Кроме того, в организованном аспекте – речь идет не об одном предприятии, а о целой системе участников процессов в ходе ЖЦ – государственные
учреждения, государственные и частные предприятия, КБ, предприятия сервиса
и т. д., объединенные общей задачей и работающие на основе общей системы правил.
Кстати, это не значит, что CALS – это только так и никак иначе. Эти же принципы могут быть использованы внутри предприятия или нескольких предприятий
или при взаимодействии предприятия и заказчика.
13
Инициатором этого подхода и доведения его до уровня международных стандартов стало Министерство обороны США в связи с необходимостью повышения
эффективности управления и сокращения затрат на информационное взаимодействие между государственными учреждениями и коммерческими предприятиями при
поставках и в ходе последующей эксплуатации вооружений и военной техники.
Возникла логистика – наука об управлении ресурсами организации в ходе
жизненного цикла. В более широком смысле под логистикой можно понимать современные технологии, на основе которых осуществляются процедуры планирования и управления процессами технического обслуживания и ремонта, материально-технического обеспечения, включая электронную эксплуатационную и ремонтную документацию. Появилось понятие CALS-информационных технологий
логистической поддержки жизненного цикла.
Под CALS-технологиями понимается принципиально новая компьютерная
система электронного описания процессов разработки, комплектации, производства, модернизации, сбыта, эксплуатации, сервисного обслуживания и утилизации
продукции военного, гражданского и двойного назначения.
CALS-среда требует не просто внедрения нового инструмента – она предполагает изменение мировоззрения относительно ведения технологических и бизнеспроцессов.
Суть идеологии CALS состоит в непрерывном интегрированном обеспечении
участников жизненного цикла данными об изделиях, связанных с ними процессах
и среде и сводится к созданию единой интегрированной модели изделия. Эта модель сопровождает изделие на протяжении всего жизненного цикла – от момента
выявления потребностей общества в определенном продукте до удовлетворения
этих потребностей и утилизации продукта. Модель должна содержать всю совокупность знаний о продукте: его проектировании, производстве, эксплуатации, обо
всех свойствах на любом из этапов его жизненного цикла. CALS-технологии предназначены для применения в различных областях экономики, в том числе в производстве промышленной продукции, банковской деятельности, здравоохранении,
строительстве и т. д.
CALS – непрерывно развивающееся понятие, содержание которого менялось
с течением времени (см. ниже).
ЭВОЛЮЦИЯ ОПРЕДЕЛЕНИЙ CALS
Годы
1985
1988
1993
1994
1995
14
Определения
Компьютерная поддержка логистических систем (Computer-Aided of Logisties
Support)
Компьютеризированные поставки и поддержка (Computer-Aided Acquisition
and Support)
Поддержка непрерывных поставок и жизненного цикла (Computer-Aided Acquisition and LifeCycle Support)
Добавлена концепция параллельного проектирования
Бизнес в высоком темпе (Commerce At Light Speed)
CALS не только успела сменить несколько раз «полное имя», но и обзавестись
«двойником». Им стала концепция PLM (Product Lifecycle Management) – управление жизненным циклом изделия – интегрированная информационная модель всех
этапов жизненного цикла изделия: от проектирования и изготовления до установки, технического обслуживания и демонтажа.
Термин возник в Европе – пока оборонная индустрия США держала свое детище «под крылом», европейская промышленность ощутила потребность в интеграции предприятий-партнеров, участников жизненного цикла продукции, вызвавшую к жизни появление аналогичной концепции. Оба термина уживаются
на рынке ИТ. В дальнейшем будем применять термин CALS.
Термин PLM используется для обозначения процесса управления полным
циклом изделия – от его концепции, через проектирование и производство до продаж, послепродажного обслуживания и утилизации. PLM – это набор возможностей, которые позволяют предприятию эффективно обновлять свои продукты
и релевантные услуги на протяжении полного бизнес-цикла. PLM – это один из
четырех краеугольных камней в ИТ-структуре любого производственного предприятия. Всем компаниям необходимо уметь работать с клиентами (см. CRM)
и поставщиками (см. SCM), а также управлять ресурсами предприятия (см. ERP).
В дополнение к этому машиностроительным компаниям необходимо уметь разрабатывать, описывать, управлять и распространять информацию об их изделиях,
для чего нужно PLM. Ключевые компоненты PLM – это управление данными
об изделии (см. PDM), совместное проектирование изделия (см. CPD, CAD, CAE),
управление производственными процессами (см. MPM, CAPP, CAM).
Можно сказать, что понятие PLM-система трактуется двояко: либо как интегрированная совокупность автоматизированных систем CAE/CAD/CAM/PDM
и ERP/CRM/SCM, либо как совокупность только средств информационной поддержки изделия и интегрирования автоматизированных систем предприятия, что
практически совпадает с определением понятия CALS. Характерная особенность
PLM – возможность поддержки взаимодействия различных автоматизированных
систем многих предприятий, т. е. технологии PLM являются основой, интегрирующей информационное пространство, в котором функционируют САПР, ERP,
PDM, SCM, CRM и другие автоматизированные системы многих предприятий.
Внедрение PLM позволяет:
– сократить время выхода изделия (или его модификации) на рынок;
– улучшить качество изделия;
– уменьшить стоимость прототипирования (см. Rapid Prototyping);
– повторно использовать оригинальные данные об изделии;
– проводить оптимизацию изделия;
– уменьшить отходы и ущерб окружающей среде;
– сэкономить благодаря полной интеграции инженерных процессов.
Среди русских специалистов применяется формулировка, аналогичная CALS.
Она выглядит следующим образом: Информационная Поддержка процессов
жизненного цикла Изделий (ИПИ). Представляется, что ИПИ – адекватный
15
русскоязычный аналог понятия CALS, в связи с чем, в дальнейшем эта аббревиатура будет использоваться вместо CALS, кроме тех случаев, когда будут описываться зарубежные стандарты и зарубежный опыт.
Сейчас в мире насчитывается более 25 национальных организаций, координирующих вопросы развития CALS-технологий. Организации действуют в США,
Канаде, Японии, Великобритании, Германии, Швеции, Норвегии, Австралии,
а также в НATO.
Обобщая сведения, взятые из различных источников, можно предложить следующее определение CALS:
CALS – концепция, объединяющая принципы и технологии информационной
поддержки жизненного цикла продукции на всех его стадиях, основанная на использовании интегрированной информационной среды (единого информационного
пространства), обеспечивающая единообразные способы управления процессами
и взаимодействия всех участников этого цикла: заказчиков продукции (включая
государственные учреждения и ведомства), поставщиков (производителей) продукции, эксплуатационного и ремонтного персонала, реализованная в соответствии с требованиями системы международных стандартов, регламентирующих
правила указанного взаимодействия преимущественно посредством электронного
обмена данными.
В настоящее время CALS необходимо понимать как технологию повышения
эффективности бизнеса, основанную на эффективном информационном взаимодействии субъектов хозяйственной деятельности и совместном использовании информации в ходе жизненного цикла изделия или продукта.
Идеология CALS основана на следующих принципах:
• все данные об изделии, процессах и ресурсах хранятся и циркулируют в цепочке предприятий-партнеров в электронном виде. Безбумажные технологии обеспечиваются использованием электронной цифровой подписи;
• данные предприятиями-партнерами не дублируются и используются многократно, что создает единую информационную сеть, обеспечивает полноту и целостность информации и позволяет минимизировать затраты на всех стадиях жизненного цикла изделия;
• единая информационная среда предполагает унификацию и оптимизацию
данных и способов доступа к ним;
• данные доступны всем партнерам цепочки, что обеспечивает интеграцию их
информационного взаимодействия;
• в производстве используется принцип параллельного инжиниринга (concurrent engineering);
• происходит непрерывное совершенствование (реинжиниринг) бизнеспроцессов.
В результате информационной интеграции создаются три интегрированные
модели:
• модель самого продукта;
• модель его жизненного цикла и его бизнес-процессов;
• модель среды производства и эксплуатации изделия.
16
Для CALS характерно следующее:
• решаются задачи интеграции всех процессов в ходе ЖЦ (в отличие от компьютерной автоматизации и интеграции отдельных процессов);
• участники информационного взаимодействия могут быть территориально
удалены друг от друга и располагаться в разных городах и странах;
• совместно используемая информация очень разнородна: это маркетинговые,
конструкторско-технологические, производственные данные, коммерческая и юридическая информация и т. д. Для обеспечения возможности ее совместного использования должны быть стандартизованы способы и технологии представления
и корректной интерпретации данных;
• основной средой передачи данных является глобальная сеть Internet.
В настоящее время внутри CALS выделяют следующие направления:
• методы анализа и реинжиниринга бизнес-процессов;
• методы и средства параллельного проектирования;
• технологии логистики;
• технологии информационного взаимодействия с поставщиками;
• практическое использование технологий Интернета/Интранета;
• электронная документация на изделие;
• электронная коммерция, информационная безопасность;
• унифицированная модель изделия от проектирования до утилизации (STEP);
• юридические вопросы информационного взаимодействия предприятий.
Целями использования CALS-технологий являются:
• сокращение затрат на реализацию жизненного цикла изделия в целом;
• повышение эффективности и сокращение затрат в бизнес-процессах;
• повышение конкурентоспособности и рыночной привлекательности производимой продукции;
• создание предпосылок для сохранения и расширения рынков сбыта.
Таким образом, CALS – это прежде всего информационная стратегия, ведущая к:
• пересмотру путей ведения бизнеса;
• использованию программных средств, поддерживающих международные
стандарты, многие из которых уже широко применяются;
• более эффективному использованию информации;
• новым методам сотрудничества между предприятиями-партнерами.
Но самое главное, CALS – ЭТО КУЛЬТУРНАЯ РЕВОЛЮЦИЯ (перемены
в идеологии).
Областями применения CALS принято считать:
• совершенствование деятельности в области разнородных процессов, происходящих на всех этапах жизненного цикла продукции;
• управление цепными поставками в течение всего жизненного цикла продукции (от создания концепции изделия до его утилизации);
• электронная интеграция организаций (предприятий), участвующих в этих
процессах на различных этапах жизненного цикла продукции;
• управление поддержкой жизненного цикла продукции.
17
Для перехода к CALS прежде всего должны быть созданы основные предпосылки, в их числе:
1. Наличие надежной высокоскоростной вычислительной сети, допускающей
быстрое расширение и изменение конфигурации.
2. Обеспечение всех участников, сопровождающих жизненный цикл изделия,
производительными рабочими станциями, подключенными к сети.
3. Наличие высокопроизводительных серверов с достаточным ресурсом дисковой памяти и системами резервного копирования.
4. Освоение специалистами конструкторских подразделений систем трехмерного проектирования и получение проектной документации в электронном виде.
5. Наличие специалистов по автоматизации, способных внедрять CALS и осуществлять техническую, программную и организационную поддержку проекта.
6. Наличие финансирования проекта в необходимом объеме.
Отметим, что отсутствие какой-либо из этих предпосылок крайне затрудняет
решение задачи перехода к CALS.
Теперь о проблемах, которые необходимо решать при внедрении. Среди них
мы выделим такие, как:
1. Классификация информации.
2. Классификация пользователей.
3. Обеспечение представления информации в нужном виде для соответствующих групп пользователей.
4. Распределение прав доступа к информации.
5. Определение статуса электронных документов.
6. Регламентация процесса внесения изменений в электронные документы.
7. Организация ввода информации в CALS-систему.
8. Организация ведения справочников.
9. Обеспечение администрирования системы.
10. Обеспечение интеграции с уже существующими CAD/CAM/CAE и ERP
системами.
11. Определение приоритетов и порядка внедрения.
12. Обеспечение участия руководства фирмы в процессе внедрения.
1.2. CALS – КОММЕРЧЕСКИ ВЫГОДНАЯ СТРАТЕГИЯ
Итак, в настоящее время CALS переводится как «непрерывное развитие
и поддержка ЖЦ». Несмотря на кажущуюся (особенно в русском варианте) бессмысленность этого названия, в нем заложены глубокие бизнес-идеи, связанные
в том числе и с организационными вопросами повышения конкурентоспособности
изделия. Согласно концепции CALS преобразование ЖЦ изделия в высокоавтоматизированный процесс должно происходить за счет реструктуризации составляющих
ЖЦ подпроцессов. Бизнес-идеи CALS касаются методики такого преобразования.
Первая часть термина «CALS» звучит как «Continuous Acquisition», что в дословном переводе означает «непрерывное приобретение». Дело в том, что ЖЦ
современного промышленного изделия (в частности, вооружений и военной техники) продолжается длительное время, измеряемое десятками лет. За это время
изделие, во избежание морального устаревания, постоянно модернизируется, приобретая, таким образом, новые качества, т. е. развиваясь.
18
С другой стороны, процесс развития изделия происходит не сам по себе, а как
результат взаимодействия поставщика и потребителя изделия (потребитель выдвигает требования, а поставщик реализует их, проводя перепроектирование и модернизацию изделия). В данном случае CALS предполагает использовать не фиксированные навсегда схемы взаимодействия поставщика и потребителя изделия,
а точно так же улучшать (развивать) их в течение всего ЖЦ изделия. Таким образом, под непрерывным развитием понимается постоянное улучшение (развитие)
в течение ЖЦ как самого изделия, так и методов взаимодействия поставщика
и потребителя.
Словосочетание «Life cycle Support» переводится как «поддержка ЖЦ». Замечено, что значительная часть проблем, возникающих при эксплуатации, обслуживании, ремонте и модернизации изделия, связана с неверными конструкторскими
или технологическими решениями, принятыми при разработке изделия.
Такие ошибки, заключающиеся в игнорировании требований перечисленных
этапов ЖЦ, оказывают значительное влияние на увеличение стоимости владения
изделием и времени вынужденного простоя изделия. Исправление подобных ошибок всегда связано с еще более значительными расходами. Идея, касающаяся поддержки ЖЦ изделия, состоит в оптимизации стоимости всего ЖЦ изделия за счет
правильного распределения затрат по этапам ЖЦ. Предлагается увеличить инвестиции в проект изделия на начальных этапах ЖЦ с тем, чтобы изделие было более
приспособлено к условиям эксплуатации.
Это может быть реализовано путем организации проектирования изделия
с использованием методик параллельного проектирования и комплексных рабочих
групп, включающих специалистов из различных предметных областей: конструкторов, технологов, экспертов по эксплуатации, обслуживанию, ремонту и модернизации изделия, а также за счет организации интегрированной логистической
поддержки изделия. В таком случае удастся снизить затраты на последующие этапы ЖЦ, и полученная экономия будет с избытком компенсировать дополнительные инвестиции на этапе проектирования. При этом в выигрыше окажется и поставщик изделия (увеличится цена изделия), и потребитель изделия (сократится
общая стоимость владения изделием).
По сравнению со странами Запада выигрыш отечественной промышленности
от такого подхода в процентном отношении должен быть еще больше (кривая 3
на рис. 1.1). Дело в том, что если на западных предприятиях возможности повышения эффективности управления неинформационными ресурсами практически
исчерпаны, то в России здесь еще существует большое поле деятельности, связанное, в первую очередь, с оптимальной организацией процессов ЖЦ.
Бизнес-идеи GALS:
• Непрерывное развитие (Continuonus Acquisition) – постоянное повышение
эффективности (развитие) как самого изделия, так и процессов взаимодействия
между поставщиком и потребителем изделия в течение его ЖЦ.
• Поддержка ЖЦ (Life cycle Sypport) – оптимизация стоимости всего ЖЦ
за счет перераспределения затрат по этапам ЖЦ.
Первоначально поэтапный подход к реализации CALS привел к выделению
двух этапов:
19
Первый этап – предполагалось, что к 1989 г. вся техническая документация
должна будет представляться в электронном виде.
Второй этап – предполагалось, что к 1991 г. вся конструкторско-технологическая документация должна быть представлена в электронном виде.
На первом этапе были определены «независимые стандарты», а также механизм обмена информацией с помощью «магнитного носителя».
На втором этапе было достигнуто соглашение, в рамках всемирного консорциума 25 ведущих технических организаций, об использовании нового стандарта
описания данных, а также осуществлен доступ Министерства обороны США к базам данных его поставщиков.
Рис. 1.1. Распределение затрат при внедрении CALS: 1 – неоптимизированное распределение затрат; 2 – оптимизированное распределение затрат; 3 – оптимизированное распределение затрат для отечественной промышленности
Следует заметить, что только лишь в 1995 г. был заключен меморандум
по общему пониманию и кооперации в использовании этого нового стандарта
STEP (ISO 10303). В данном меморандуме отмечено, что новый стандарт является
ключевой технологией описания данных об изделии для мирового рынка. Этот
стандарт, называемый обычно STEP, обеспечивает описание физических и функциональных параметров изделия на протяжении всего его жизненного цикла.
Меморандум, подписанный 11 руководителями главных аэрокосмических
компаний США, содержит обязательство участников использовать STEP в реализации CALS. Этот меморандум подталкивал своих поставщиков, других участников аэрокосмической отрасли и продавцов ее технических систем к участию в разработке и внедрении STEP-технологии. В меморандуме указывается, что в настоящее время различные компании нуждаются в эффективном обмене информацией
с их партнерами, заказчиками и поставщиками во всем мире. Для того чтобы сохранить конкурентоспособность на мировом рынке, эти компании должны быть
уверены, что обмен является совместимым, точным и своевременным.
Используя эти международные стандарты, компании устраняют существовавшие при обмене информацией барьеры, что позволяет обеспечить максимальную гибкость при конструировании, производстве и логистической поддержке
продукции. Использование международных стандартов STEP даст возможность
этим аэрокосмическим компаниям (и компаниям других отраслей) достигнуть
новых, более высоких показателей качества и производительности, снижения
стоимости продукции и сокращения времени выхода ее на рынок.
20
Характерно, что рассматриваемый меморандум схож с международным меморандумом автомобилестроительных компаний.
К ключевым областям CALS относят:
• реорганизацию предпринимательской деятельности;
• параллельное проектирование;
• электронный обмен данными;
• интегрированную логистическую поддержку;
• многопользовательскую базу данных;
• международные стандарты.
Существенным моментом является то, что ни одну из областей CALS нельзя
рассматривать в отрыве от других. Именно это обстоятельство не позволяет относить к CALS следующее:
• просто набор международных стандартов;
• стандартный набор правил организации деятельности предприятий;
• стандартный набор программно-технических инструментов для интеграции
предприятий;
• компьютеризированную систему создания технической документации;
• электронный обмен данными для организации поставок по принципу «точно
вовремя».
Реализация CALS предпринимателями и промышленниками позволит: увеличить производительность труда своих сотрудников; сократить временные и общие
материальные затраты и обеспечить общее повышение качества. Этого можно будет достичь путем: упрощения доступа к информации; реорганизации деятельности (без изменения поставленных задач); компьютеризации рабочего окружения;
изменения взаимосвязей между предприятиями-партнерами, а также за счет повышения показателей качества выполнения следующих операций:
• обработки информации;
• использования информации;
• осуществления консультаций и аналитического обзора результатов работы;
• пересмотра информации;
• добавления новой информации;
• переделки информации;
• просмотра/утверждения информации;
• распространения информации;
• работы над ошибками, анализа причин их возникновения.
Поэтому любое предприятие – мелкое, среднее или крупное, планирующее
освоить производство нового изделия, а также осуществить его эффективную технико-экономическую поддержку, сможет извлечь выгоду, используя такие преимущества CALS-технологий, как одноразовое создание и многоразовое использование общих данных и планирование жизненного цикла.
Эти предприятия будут способны: быстрее реагировать на изменение рыночной ситуации (оптимальная реакция на запросы потребителей, сокращение времени
на пополнение материальных запасов и снижение их объема); уменьшить свои затраты (устранение трудоемких операций по дублированию данных, значительное
21
сокращение объемов используемой бумаги); повысить качество, особенно надежность своей продукции (уменьшение брака на этапах разработки и производства
изделий, улучшение согласованности данных).
1.3. ПРИМЕРЫ РЕАЛИЗАЦИИ CALS ЗА РУБЕЖОМ
Введение международных стандартов по CALS-технологиям позволяет интегрировать в одну систему комплекс материальных и информационных потоков, существующих на всех этапах жизненного цикла продукции. Отсутствие единого
комплекса стандартов описания продукции на всех этапах ее жизненного цикла
приводит к значительным дополнительным издержкам при создании и эксплуатации изделий. Эти издержки западными аналитиками оцениваются в масштабах
промышленности США в десятки миллиардов долларов в год.
Концепция CALS-технологий на первом этапе ее разработки заключалась
в унификации и объединении разнотипных компьютерных сетей промышленных
корпораций с целью создания глобальной системы закупок и материальнотехнического снабжения, используемой при создании сложной машинотехнической продукции, в том числе вооружения и военной техники. В ходе выполнения
программы реализации CALS-технологий ее первоначальный замысел существенно трансформировался и в настоящее время превратился в инструмент компьютеризированного проектирования, производства, поставок, эксплуатации сложных
машинотехнических изделий, а также профилактических и ремонтных работ
в процессе их эксплуатации.
CALS – это стратегия промышленности и правительства, направленная
на эффективное создание, обмен, управление и использование электронных данных, поддерживающих жизненный цикл изделия с помощью международных
стандартов, реорганизации предпринимательской деятельности и передовых технологий. CALS-ориентированный подход внедряется заказчиками и поставщиками
во многих отраслях промышленности: от автомобилестроения до предприятий
ВПК; от здравоохранения до производственной сферы. Каждое из предприятий
адаптирует принципы CALS-технологий для выполнения как общих, так и частных
задач. Между тем различные отрасли находятся на различных стадиях внедрения
CALS: от полной деинтеграции информации до разработки и широкой реализации
CALS-технологий.
Так, с конца 80-х гг., когда военные расходы стали уменьшаться, Newport
News Shipbuilding (филиал Tenneco Corp.) работал над расширением своего сектора на мировом рынке, одновременно оставаясь полноценным подрядчиком в области военных заказов. Направляя свои усилия на модернизацию, Newport News
инвестировал почти 15 млн долларов в создание телекоммуникационной инфраструктуры. В результате появилась обширная сеть по поддержке более 10 000 активных пользователей и более 6 000 рабочих станций, объединенных в сети.
Френсис Б. Брейк (Frank Brake), начальник отдела «Logistics engineering», отмечал, что в этих условиях фактором, подталкивающим к ускорению внедрения
CALS, является значительная трудоемкость проектирования и строительства
22
судов. Причем по мере усложнения этих судов становилось все более очевидным,
что затраты на процессы проектирования, строительства, эксплуатации и управления растут так быстро, что если не принять энергичных мер, то весь бюджет будет
израсходован еще до периода их эксплуатации. Реализация CALS предоставила
Newport News Shipbuilding возможность управлять структурой расходов, вписываясь в рамки ассигнований на протяжении всего жизненного цикла судов.
Философия проектирования как часть философии «Жизненного цикла продукции» родилась в Департаменте обороны США в 1987 г., когда Newport News
получил от ВМФ заказ на разработку проекта подводной лодки «морской волк».
Это было первое изделие, где появилась широкомасштабная возможность заставить работать идеи CALS и использовать усовершенствованный опыт и новую
технологию для производства миллионов отдельных узлов лодки с соблюдением
одинаково высоких требований как по качеству, так и по совместимости друг
с другом.
В то время компьютерные системы, закупленные военными ведомствами
с целью усовершенствования процессов создания и технического обслуживания
военной техники, не могли обмениваться информацией между собой и с аналогичными системами, использовавшимися в промышленности. Это приводило к изоляции вычислительных систем, ставших похожими на островки автоматизированной
обработки данных.
«Морской волк» явился первой полностью электронной разработкой. Проект
содержит 2D-, 3D-проволочные модели, твердотельные модели, данные технических расчетов. Компьютеризированный процесс проектирования задействовал
геометрические модели, сгенерированные не только Newport News, но и General
Dynamic/ Electric Boat Div., эксклюзивным подрядчиком в области данных разработок. Существенным фактором, как отмечал Френсис Б. Брейк, явилось также
управление процессом проектирования, которое имело прямым результатом устранение многих конструкционных ошибок. С использованием CALS-подхода
Newport News значительно сократил срок проектирования. Параллельное проектирование концентрировалось вокруг идеи использования предельно большой 3Dтвердотельной модели, заключающей в себе более 1,5 млн узлов, которая (модель)
была разработана как составляющая одну целую «сущность», позволяя всем участвующим группам взаимодействовать с геометрической моделью одновременно.
Технический анализ, планирование производства, монтаж узлов и другие процессы теперь удалось проводить параллельно. Newport News также использовал
CALS-подход при создании авианосцев. «Эти авианосцы укомплектованы каждый
более чем 6 тыс. военнослужащих ВМФ США», – объясняет Френсис Б. Брейк.
«До недавних пор период создания этих судов составлял 7 лет. Но с применением
CALS, мы сократили срок до 5,5 лет. В случае с "Т. Рузвельтом" мы закончили еще
на 18 месяцев раньше, сэкономив 80 млн долларов». Это один из примеров реализации CALS, подтверждающий реальное улучшение процессов проектирования
и строительства крупных объектов.
Самолетостроительные компании и авиалинии США тоже нашли пути внедрения CALS-систем для интенсификации информационных потоков и снижения
23
своих затрат. Например, в Boing CALS-системы использовались для сокращения
времени проектирования и уменьшения количества технической документации
при реализации проекта 777.
United Airlines, со своей стороны, развивает CALS-систему для децентрализации эксплуатационной службы и связывания воедино таких функций предприятия,
как финансовая отчетность, инженерные расчеты, управление инвентаризацией
и собственно производство.
Наконец, Hughes Aircraft внедрила систему управления (систематизации) данными о своих изделиях, которая позволяет ее правительственным заказчикам
и поставщикам комплектующих получать доступ ко всем данным о каждом изделии.
Используя перекрестные функциональные связи при 3-мерном геометрическом моделировании, группы проектировщиков Boeing отказались от полномасштабного моделирования главных сборочных единиц. Применение электронного
описания изделий и электронной передачи данных непосредственно на производстве и поставщиками комплектующих помогло снизить число конструкционных
изменений и ошибок, а также прорабатывать проект сверху вниз. Введение принципа «обязательности» компьютеризации произошло только после того, как технологические процессы были целиком выверены, улучшены, перепроектированы,
где необходимо, затем связаны воедино перекрестными функциональными связями.
Одним из проявлений такой общей интеграции явилась помощь в сокращении
количества технической документации, оказанная Boeing фирмой Computer
Resources International Inc. (CRI). CRI применила программное обеспечение для
преобразования формата данных по методологии, названной Р+ (поставляемой
DMR Group) и три стандарта CALS для работы с текстом (SGML); как с векторными (CGM), так и с растровыми (CCITT) графическими данными.
В Boeing ожидают, что будет достигнуто сокращение затрат времени на разработку технической документации. При этом возможны дальнейшие CALSизыскания. Ник Коппинг, президент CRI, считает: «Возможности сокращения времени проектирования, улучшения качества и отслеживания затрат реализуются
дальнейшим применением удачной модели Boeing как к поставщикам, так
и на авиалиниях, где адаптируются и развертываются CALS-стандарты».
United Airlines является одним из покупателей Boeing, применяющим интеллектуальную CALS-систему информации об эксплуатационной поддержке, которая обеспечивает расширенные возможности планирования и управления службой
технической поддержки, снижение затрат на учет имеющихся в наличии запасных
частей и уменьшение количества самолетов, недоступных для обслуживания
в один и тот же момент времени.
Джон Керфи, бизнес-разработчик проекта EMSYS, на котором базируется
вышеуказанная система, отмечает: «Мы на практике установили значительное увеличение наших эксплуатационных и технических мощностей. Вдобавок, мы децентрализовали нашу службу поддержки. Прежде у нас имелась одна ремонтная база
в Сан-Франциско, поддерживающая сервисные станции зависимых авиалиний
24
в целом по США. Теперь у нас есть другая мощная база в Окланде, и еще одна
строится в Индианаполисе».
Hughes-система управления данными об изделии основывается на правительственном стандарте интегрированной службы технической информации подрядчика (CITIS), что для всех авторизованных пользователей системы означает возможность доступа к графическим и текстовым данным, а также к данным о моделях
с помощью своих компьютеров. Программное обеспечение, которое осуществляет
такой доступ, хранит данные в нейтральном CALS-формате.
В 1985 г. Департамент обороны приступил к разработке CALS для решения
вставших перед ним проблем. Таким образом, Министерство обороны США стало
основоположником CALS. В мае 1989 г. Министерством обороны было осуществлено исследование в области CIRPLS. CIRPLS – это интегрированные автоматизированные системы разработки требований к изделиям и логистической поддержки.
После проведения консультаций в январе 1991 г. с представителями промышленности в середине 1993 г. был создан комитет, руководящий реализацией CIRPLS.
Создание инфраструктуры CIRPLS датируется 1993 г. Определен поэтапный план
реализации в течение 10 лет. В рамках создания вышеуказанной системы создавалась интегрированная логистическая поддержка. Ее можно рассматривать как
классический случай реорганизации деятельности предприятия. Интегрированная
логистическая поддержка предшествовала CALS. В ее рамках решение вопросов
поддержки жизненного цикла изделий переносится на стадии проектированияэксплуатации. Другими словами, эксплуатационная поддержка становится одним
из главных факторов, влияющих на процесс проектирования.
Помимо этого, но взаимосвязано с интегрированной логистической поддержкой, в Министерстве обороны США используются различные базы данных об изделиях, и, как следствие, здесь принята концепция Интегрированной базы данных
по системам вооружений (IWSDB). Существует также и гражданский вариант этой
концепции расширенной базы данных об изделиях (EPDB). Впоследствии Министерство обороны США пересмотрело первоначальную концепцию, которая теперь
стала Интегрированной системой подрядчика для предоставления технической
информации SERVICE (CITIS).
Для развития методологии CALS 1100 представителей промышленности
США в 1987 г. выступили с инициативой создания Промышленной ассоциации
по вопросам национальной безопасности – Американского промышленного управляющего комитета в области CALS (CALS Industry Steering Group – ISG). Задача
этой организации – оказывать серьезную помощь в распространении CALSконцепции об экономическом росте, основанном на интеграции предприятий.
CALS характеризуется как универсальное средство повышения конкурентоспособности в различных отраслях промышленности. Данный Комитет координирует работы различных организаций США в области CALS.
Так, например, United Airlines, со своей стороны, развивает CALS-систему для
децентрализации эксплуатационной службы и связывания воедино таких функций
предприятия, как финансовая отчетность, инженерные расчеты, управление инвентаризацией и собственно производство. С появлением Национальной информационной
25
инфраструктуры (NII – National Information Infrastructure) в США ожидается
трансформация всего подхода к ведению бизнеса в глобальном масштабе. CALS,
как ее базис, предписывает NII помогать заинтересованным лицам в понимании
стандартов и развивать стратегии генерации, обмена и управления цифровыми
данными.
Как следствие этого, в 1991 г. была создана CSRC-программа для содействия
в передаче технологий между правительством, бизнесом, научной базой и производством. CSRC – это сеть из 7 CALS-центров с совместно используемыми ресурсами, обеспечивающая повседневную, оперативную связь между правительством
и промышленностью.
В настоящее время во всех развитых странах созданы национальные комитеты
по развитию CALS-тсхнологий, которые активно ведут работы по их реализации.
Так, например, в Великобритании CALS стала известна с 1988 г. В 1991 г. был
сформирован Промышленный совет Великобритании в области CALS (UKCIC).
С 1993 г. Министерства торговли и промышленности Великобритании начали содействовать развитию CALS. В том же году было выпущено руководство
по внедрению CALS. Свою задачу UKCIC видит в продвижении и поддержке наилучших методов реорганизации предпринимательской деятельности так, чтобы
компании Великобритании могли воспользоваться преимуществами электронного
обмена информацией. Самыми первыми предприятиями, начавшими применение
CALS, являются: аэрокосмический комплекс, военно-промышленный комплекс,
крупные компании, в том числе нефтяные и нефтеперерабатывающие. Самыми
первыми проектами в области CALS в Великобритании были проекты, связанные
с организацией цепных поставок между «первопроходцами» в области CALS.
В Европе CALS начинает достаточно широко распространяться. Создана Европейская промышленная группа в области CALS, создаются национальные программы по CALS, а также отдельные проекты по CALS, такие как: EPDEN,
PROSTEP, PISTEP и другие.
НАТО также уделяет значительное внимание вопросам CALS. Ведомство по
вопросам CALS в структуре НАТО создано в 1994 г. В рамках данного ведомства
осуществляются исследования, охватывающие: технические стандарты, функциональные МЕТА модели; сетевую инфраструктуру, анализ рентабельности, принципы электронной коммерции, правовые вопросы и контрактное право. НАТО принял инициативы системы CALS для сокращения закупок вооружения, оперативной
логистики и связанных с этим эксплуатационных расходов.
Руководство системы CALS НАТО (NCMB) требует международной согласованности переоснащения и логистики систем вооружения. В 1993 г. был проведен
семинар НАТО по координации переоснащения и логистики (ALHW – the NATO
Acquisitions and Logistics Harmonization Workshop), задачей которого являлся анализ существующих методов поставки техники и претворения в жизнь в рамках
НАТО наиболее эффективных из них. Цель семинара состояла в упорядочении координации и обмена информацией о системах вооружения между министерствами
обороны государств – членов блока и поставщиками и изготовителями оборонной
техники.
26
Для претворения в жизнь усилий по координации переоснащения и модернизации процесса материально-технического обеспечения НАТО использует технический прием моделирования, называемый интегрированным языком определений
IDEF (Integrated Definition language). IDEF принят в США в качестве федерального
стандарта обработки информации и поддержан Национальным институтом стандартов и технологий NIST, Институтом инженеров по электротехнике и электронике IEEE и группами пользователей IDEF. Сейчас IDEF также принят в НАТО как
стандарт моделирования процессов и данных и используется как наиболее эффективный международный язык передачи данных в 16 государствах-членах блока
и в космической и оборонной промышленности.
Система CALS использовалась в НАТО для создания структуры и выработки
стандартов и руководящих принципов закупки систем вооружения. Цель состояла
в том, чтобы создать систему, в которой все значимые элементы НАТО – действующее командование, государства – члены блока и т. д. – могли бы использовать
данные совместно с промышленностью. Ввиду большой разнородности элементов,
подлежащих координации, ALHW нуждался в компьютеризированном отображении процесса и соответствующих методах анализа и проектирования наиболее эффективных процессов материально-технического снабжения.
Министерство внешней торговли и промышленности Японии приступило
к осуществлению широкомасштабной программы разработки, испытаний и внедрения системы CALS. Программа объединяет более двадцати взаимосвязанных
проектов, охватывающих различные отрасли экономики, включая авиационнокосмическую, судостроительную, электронную, автомобилестроительную, финансовую и другие. В соответствии с программой в 1998 г. проведено испытание электронных документов, программных средств, созданных для организации производства высокотехнологичной продукции. На реализацию указанной программы, наряду с частными инвестициями, государством ежегодно выделяется около двухсот
миллионов долларов. При этом государственная поддержка полностью связана
с общей стратегией реализации новейших информационных технологий и нацелена на обеспечение конкурентоспособности национальных товаров на мировых
рынках. Новейшие разработки японских фирм апробированы, в первую очередь,
при производстве вооруженной и военной техники (ВВТ). Кроме того, намечено
спроектировать и испытать в «виртуальных компьютерных предприятиях» разработку, производство и сбыт ряда бытовых изделий широкого потребления.
В 1995 г. был создан Промышленный форум. В рамках него осуществляются
различные проекты в области CALS. Например, два из них, которые оцениваются
особенно высокой вероятностью их реализации:
• Национальный проект «N-CALS» (ассигнования 35 300 000 $ за три года);
• Международный проект «MATIC» (ассигнования 17 700 000 $ за три года).
В международном проекте «MATIC» участвуют Сингапур, Малайзия, Индонезия,
Таиланд, Китай и Япония.
Развитие системы CALS-технологий приведет к тому, что в ближайшие несколько лет мировой рынок наукоемких технологий, так же как рынок промышленной кооперации, полностью перейдет на стандарты CALS-технологий и будет
оперировать только с продукцией, имеющей электронную документацию.
27
Таким образом, ведущие страны мира в последние годы разработали инструментальные программные средства, реализующие комплекс международных стандартов по CALS-технологиям, и провели успешную апробацию новейших компьютерных технологий на основных этапах жизненного цикла высокотехнологичной
продукции.
1.4. СТРАТЕГИЯ ФОРМИРОВАНИЯ И РАЗВИТИЯ CALS-ТЕХНОЛОГИЙ
В ПРОМЫШЛЕННОСТИ РОССИИ
Перед отечественной промышленностью стоит чрезвычайно актуальная проблема разработки инструментального программного обеспечения, необходимого
для приведения имеющихся разработок безбумажных электронных технологий
в соответствие с требованиями принятых международных стандартов.
Изолированность российской промышленности от активно создаваемых
в развитых странах CALS-технологий может уже в ближайшие годы привести
к потере наших позиций на внешнем рынке машинотехнической продукции, поскольку отечественные изготовители не смогут обеспечить их электронное безбумажное сопровождение в соответствии с новыми международными стандартами.
Кроме того, наукоемкая отечественная продукция не сможет конкурировать с продукцией развитых стран из-за того, что применение CALS-технологий снижает
себестоимость продукции и повышает эффективность ее эксплуатации.
Отставание российской промышленности в области CALS-технологий может
привести к невосполнимому отставанию России в этой области, в значительной
степени определяющей не только уровень национальной технологической базы,
но и экономическую и оборонную безопасность страны. Для решения проблемы
разработки и внедрения в промышленности России CALS-технологий потребуется
решение комплекса структурно-организационных, экономических, методологических, технических и правовых вопросов. В частности, необходимо создать и обеспечить функционирование соответствующей сети научно-исследовательских, информационно-технических и учебно-методических центров.
CALS необходимо использовать как инструмент достижения следующих
стратегических целей:
• сохранение статуса индустриальной державы, путем сохранения существующих рынков сбыта и их развития;
• увеличения объема производства, национального дохода и налоговых поступлений.
Уже сегодня иностранные заказчики отечественной военно-технической продукции выдвигают требования, удовлетворение которых невозможно без внедрения ИПИ-технологий:
• представление конструкторской и технологической документации в электронной форме;
• представление эксплуатационной и ремонтной документации в форме интерактивных электронных технических руководств (ИЭТР), снабженных иллюстрированными электронными каталогами запасных частей и вспомогательных материалов и средствами дистанционного заказа запчастей и материалов;
28
• организация системы интегрированной логистической поддержки изделий
на постпроизводственных стадиях их ЖЦ;
• наличие и функционирование электронной системы каталогизации продукции;
• наличие на предприятиях соответствующих требованиям стандартов ИСО
9000:2000 систем менеджмента качества и т. д.
Выполнение этих требований предопределяет необходимость внедрения
на отечественных предприятиях систем, реализующих ИПИ-технологии в полном
объеме.
1.5. МЕРОПРИЯТИЯ МИНПРОМНАУКИ ПО ВНЕДРЕНИЮ ИПИ-ТЕХНОЛОГИЙ
Минпромнауки России уделяет большое внимание развитию ИПИ-технологий.
В 1999–2002 гг. Минпромнауки совместно с Госстандартом и Минобразования
приняло ряд мер, направленных на реализацию ИПИ-технологий в промышленности России, в первую очередь в оборонно-промышленном комплексе. К их числу
относятся:
1. Организационные меры
Созданы начальные элементы инфраструктуры, необходимой для разработки
и внедрения ИПИ-технологий в промышленности России, в том числе:
Государственный научно-образовательный центр CALS-технологий.
Научно-исследовательский центр CALS-технологий «Прикладная логистика».
В 1999 г. приказом Госстандарта РФ № 515 от 01.12.99 Технический комитет
ТК 431 Госстандарта России, координирующий разработку отечественной нормативной базы.
31 августа 2004 г. Фонд поддержки информационных технологий в авиационной и ракетно-космической промышленности. В Фонд входят стратегические
предприятия, перечень которых был утвержден Президентом РФ 4 августа 2004 г.
2. Научно-методические разработки
Концепция развития ИПИ-технологий в промышленности России (утверждена
решением Коллегии Минпромнауки России 10.08.01).
Концепция интегрированной логистической поддержки наукоемких изделий.
Концепция внедрения СALS-технологий на машиностроительном предприятии.
Межотраслевая целевая комплексная программа повышения эффективности
оборонно-промышленного комплекса России в 2005–2010 гг. и на период до 2020 г.
3. Разработки в области создания нормативной базы
Ряд новых государственных стандартов и рекомендаций по стандартизации
(разработан и утвержден Госстандартом России).
Межведомственная программа работ по подготовке новых стандартов и корректировке существующих (ЕСКД, СРПП и др.).
4. Разработки программных средств
Ряд программных средств, реализующих ИПИ-технологии, в том числе система управления данными об изделии.
29
Система автоматизированной подготовки интерактивных электронных технических руководств (ИЭТР) и электронных каталогов.
Комплекс программно-методических средств компьютерной поддержки системы менеджмента качества.
Необходимо подчеркнуть важность и значимость разработки импортозамещающих программных решений, отсутствие которых сдерживает внедрение ИПИтехнологий в промышленности России по двум основным причинам:
• высокая стоимость зарубежных систем и их закрытость для пользователя,
что затрудняет их развитие и сопровождение;
• ограниченная возможность использования таких систем на оборонных
предприятиях в связи с проблемами соблюдения секретности разработок.
5. Пилотные проекты
Во исполнение решений Комиссии Правительства РФ по военно-промышленным вопросам, Минпромнауки России, совместно с российскими агентствами
оборонных отраслей промышленности, на ряде ведущих предприятий ОПК организовано выполнение комплекса пилотных проектов, направленных на внедрение
ИПИ-технологий в процессы ЖЦ различных видов наукоемкой продукции.
1.6. МЕЖВЕДОМСТВЕННАЯ ПРОГРАММА РАЗВИТИЯ
И ВНЕДРЕНИЯ ИПИ-ТЕХНОЛОГИЙ
Программа должна содержать следующие основные разделы:
• развитие нормативно-правовой и методической базы;
• развитие организационной инфраструктуры;
• фундаментальные исследования;
• прикладные разработки и пилотные проекты;
• подготовка и переподготовка специалистов.
Системной целью программы является повышение конкурентоспособности
и существенное сокращение затрат и сроков разработки, освоения производства
и вывода отечественной наукоемкой продукции на мировой рынок.
В рамках раздела «Развитие нормативно-правовой и методической базы»
должны быть разработаны:
• комплекс государственных и отраслевых стандартов, определяющих основные положения по разработке и применению электронной документации;
• комплекс стандартов по вопросам интегрированной логистической поддержки (ИЛП), учитывающих требования Федеральной системы каталогизации
продукции;
• комплекс стандартов, регламентирующих информационные технологии
представления конструкторско-технологических и производственных данных,
включая технологии управления конфигурацией сложных изделий;
• комплекс стандартов, регламентирующих информационные технологии разработки и использования эксплуатационной и ремонтной документации и др.
В рамках раздела «Развитие организационной инфраструктуры» должны
быть выполнены следующие работы:
30
• создание федерального центра развития ИПИ-технологий;
• создание отраслевых и региональных центров развития ИПИ-технологий;
• создание межведомственного координационного научно-технического совета по ИПИ-технологиям и разработка организационно-распорядительных документов по финансированию и управлению пилотными проектами;
• создание и обеспечение функционирования Интернет-портала по распространению информации в области ИПИ и электронного бизнеса и др.
В рамках раздела «Фундаментальные исследования» необходимо разработать:
• методы, средства и технологии моделирования, анализа, оптимизации и реинжиниринга бизнес-процессов производственной и коммерческой деятельности
промышленных предприятий и корпораций при переходе к работе в ИИС;
• базовые модели, принципы и технологии организации конструкторскотехнологической, производственной и коммерческой деятельности в ИИС;
• научно-методические основы интегрированной логистической поддержки
(в том числе логистического анализа – ЛА) ЖЦ изделий с целью обеспечения
их эффективной эксплуатации, обслуживания и ремонта.
В разделе «Прикладные разработки и пилотные проекты» предполагается:
• разработка и внедрение комплекса типовых моделей, методик и программно-технических решений по организации и управлению производственной деятельностью на основе компьютерных систем (Enterprise Resource Planning – ERP),
принципов электронного бизнеса и ИПИ-стандартов;
• разработка решений в области CAD/CAM/PDM-систем, рекомендаций по их
применению и внедрению в различных отраслях промышленности для электронного представления конструкторских и технологических данных об изделиях;
• разработка и внедрение комплекса программно-технических решений
по подготовке сопроводительной электронной технической документации;
• разработка и внедрение базовых программно-технических решений, обеспечивающих безбумажный обмен технической информацией;
• разработка и внедрение комплекса типовых программно-технических решений для создания компьютерных (автоматизированных) систем управления качеством продукции, соответствующих требованиям стандартов ИСО серии 9000 версии 2000 г.;
• разработка и внедрение комплекса программно-технических решений, необходимых для реализации системы интегрированной логистической поддержки изделия (логистический анализ, закупка, поставка, ввод в действие, эксплуатация,
обслуживание, поставка запасных частей, ремонт, утилизация).
В части пилотных проектов предполагается внедрение ИПИ-технологий
на предприятиях авиационно-космической и автомобильной промышленности,
в судостроении, энергомашиностроении, в производстве медицинской техники
и других отраслях.
Раздел «Подготовка и переподготовка специалистов» предусматривает:
• организацию в высших технических учебных заведениях специальности
(специализации) по проблематике ИПИ;
31
• организацию в образовательных учреждениях повышения квалификации руководящих работников и специалистов тематических курсов по проблематике
ИПИ;
• разработку и издание в бумажной и электронной форме учебнометодических материалов по ИПИ-технологиям.
Реализация Программы позволит сократить отставание промышленности России в части применения ИПИ-технологий, в первую очередь, на предприятиях,
производящих наукоемкую продукцию, обеспечивая необходимый минимум условий выхода этой продукции на внешние рынки. Кроме того, реализация Программы позволит создать базу для расширения функциональных возможностей ИПИтехнологий, более глубокого их проникновения в производственную среду предприятий различных отраслей отечественной промышленности.
1.7. ТЕХНИКО-ЭКОНОМИЧЕСКИЕ ПРЕИМУЩЕСТВА ИПИ-ТЕХНОЛОГИЙ
Технические преимущества ИПИ-технологий. Технологии, стандарты
и программно-технические средства ИПИ обеспечивают эффективный и экономичный обмен электронными данными и безбумажными электронными документами, что дает следующие преимущества:
• возможность параллельного выполнения сложных проектов несколькими
рабочими группами (параллельный инжиниринг), что существенно сокращает время разработок;
• планирование и управление многими предприятиями, участвующими в ЖЦ
продукции, расширение и совершенствование кооперационных связей (электронный бизнес);
• резкое сокращение количества ошибок и переделок, что приводит к сокращению сроков реализации проектов и существенному повышению качества продукции;
• распространение средств и технологий информационной поддержки на послепродажные стадии ЖЦ – интегрированная логистическая поддержка изделий.
Экономические преимущества ИПИ-технологий. Использование предприятиями технологий ИПИ существенно влияет на их экономические показатели.
В частности, оно приводит к:
• сокращению затрат и трудоемкости процессов технической подготовки
и освоения производства новых изделий;
• сокращению сроков вывода на рынок новых конкурентоспособных изделий;
• сокращению брака и затрат, связанных с внесением изменений в конструкцию;
• увеличению объемов продаж изделий, снабженных электронной технической документацией (в частности, эксплуатационной), в соответствии с требованиями международных стандартов;
• сокращению затрат на эксплуатацию, обслуживание и ремонты изделий
(«затрат на владение»), которые для сложной наукоемкой продукции подчас равны
или превышают затраты на ее закупку.
32
Вот некоторые количественные оценки эффективности внедрения CALS
в промышленности США:
• прямое сокращение затрат на проектирование – от 10 до 30 %;
• сокращение времени разработки изделий – от 40 до 60 %;
• сокращение времени вывода новых изделий на рынок – от 25 до 75 %;
• сокращение доли брака и объема конструктивных изменений – от 23 до 73 %;
• сокращение затрат на подготовку технической документации – до 40 %;
• сокращение затрат на разработку эксплуатационной документации – до 30 %;
• сокращение количества ошибок при передаче данных – до 90 %;
• сокращение стоимости информации – до 90 %.
По зарубежным данным, потери, связанные с несовершенством информационного взаимодействия с поставщиками, только в автомобильной промышленности США оцениваются в сумму порядка $1 млрд в год. Аналогичные потери имеют
место и в других отраслях промышленности.
В тех же источниках указывается, что затраты на разработку реактивного двигателя GE 90 для самолета Боинг 777 составили $2 млрд, а разработка новой модели автомобиля компании Форд стоит от $3 до 6 млрд. Это означает, что экономия
от снижения прямых затрат на проектирование только по двум указанным объектам может составить от $500 млн до $2,2 млрд. Отсюда следует, что внедрение
CALS-технологий приводит к существенной экономии и получению дополнительной прибыли.
В связи с большими объемами ожидаемой экономии и дополнительных прибылей от внедрения современных ИТ в эту сферу привлекаются значительные инвестиции, измеряемые миллионами и даже миллиардами долларов. По данным зарубежных источников, инвестиции правительства США в сферу CALS-технологий составляют $1 млрд в год.
Затраты других стран, естественно, меньше, однако, например, правительство
Финляндии затратило на национальную программу в этой области свыше $20 млн
и примерно такую же сумму (около $25 млн) вложили в эту программу частные
компании. Корпорация General Motors в течение 1990–1995 гг. израсходовала на
эти цели $3 млрд. Средние затраты на один проект, посвященный решению локальной задачи в области CALS-технологий (например, разработка стандарта или
программы), составляют $1,2–1,5 млн при среднем сроке выполнения от 2 до 4 лет.
Эти цифры свидетельствуют о том, какое значение придают в развитых странах
проблематике, связанной с CALS-технологиями.
1.8. СТРАТЕГИЯ РАЗВИТИЯ ПРЕДПРИЯТИЙ
В развитых странах, и в первую очередь в США, еще в начале 90-х гг. прошлого века пришли к выводу, что одни лишь финансовые данные не решают фундаментальных проблем бизнеса. Наряду с «финансовым» подходом следует оценивать мощные нематериальные активы, такие как информационные ресурсы и «человеческий капитал», а также взаимоотношения внутри организации и вне ее –
с клиентами и контрагентами. Иначе говоря, система оценки деятельности любой
33
организации (коммерческой, некоммерческой, государственной) должна содержать
как финансовые, так и нефинансовые показатели. Естественно, что эти оценки
должны быть количественными и сбалансированными между собой.
В общем случае сбалансированную систему показателей (ССП) можно определить как тщательно подобранный набор показателей на основе стратегии организации. Взятые для сбалансированной системы показатели являются инструментом руководителей для ознакомления работников и других заинтересованных лиц
с результатами и факторами деятельности, благодаря которым организация выполнит свою миссию и стратегические задачи. При этом ССП может использоваться
как инструмент распространения информации, оценочная система или система
стратегического управления.
Для оценки эффективности деятельности государственных управленческих
структур 3 августа 1993 г. президент США Билл Клинтон подписал акт, в соответствии с которым все федеральные органы были обязаны разрабатывать общие итоговые цели, цели и задачи внутренней деятельности и определять «показатели, используемые для оценки успеха в выполнении целей и задач».
В конечном счете государственные организации стали увязывать свои бюджеты с результатами деятельности, что привело к улучшению порядка их финансирования и оптимизации управления.
Когда мы говорим об организации, например авиационной или ракетнокосмической, производящей высокотехнологичную продукцию, то понимаем, что
в каждом случае речь идет фактически о корпорации (виртуальной или юридической), в состав которой входит большое количество предприятий-контрагентов.
С позиций цивилизованных рыночных отношений конкурентоспособность
продукции можно определить как «степень удовлетворения потребностей клиента
со стороны поставщика в качестве и стоимости товара и сопутствующих этому товару услугах. Финансовая оценка деятельности организации (корпорации), производящей такую продукцию, дает представление о состоянии организации на момент оценки, но не может предсказать перспективу, особенно долгосрочную. Это
объясняется тем, что при таком подходе не учитываются нематериальные активы,
которые, по оценкам зарубежных специалистов, в настоящее время составляют
не менее 80 %» (рис. 1.2).
38 %
62 %
75 %
1982
1992
2000
Рис. 1.2. Тенденция увеличения стоимости нематериальных активов
Значительный рост нематериальных активов за последние два десятилетия
объясняется, в первую очередь, переходом человечества от общества промышленного к обществу информационному и широкомасштабным внедрением информационных технологий в различных сферах жизни и деятельности человека, включая
производство и все процессы управления.
34
Если организация заботится об обеспечении своей конкурентоспособности
не только сегодня, но и в ближайшей и долгосрочной перспективе, то руководству
следует решать вопросы достаточно достоверной оценки деятельности организации с обязательным учетом нематериальных активов. Причем оценки, которая является количественной по определенным показателям, сбалансированным между
собой на основе стратегических целей организации.
Системный подход в вопросах определения перспектив развития любой организации предусматривает разработку и реализацию стратегии ее деятельности, позволяющей обеспечить стабильное конкурентное преимущество на рынке.
При этом стратегия не должна быть догмой, а обязана постоянно совершенствоваться и корректироваться в зависимости от изменения как внутренней, так внешней ситуации. При правильной постановке задачи в организации должно быть подразделение стратегического планирования, работающее в тесном контакте с руководителями проектов по внедрению информационных технологий и их службами.
При реализации стратегии неизбежно возникнут барьеры, типичная схема которых приведена на рис. 1.3.
.
Рис. 1.3. Схема барьеров на пути реализации стратегии развития организации
Именно стратегия развития корпорации дает возможность провести полноценную оценку деятельности организации как на текущий момент, так и в перспективе. Она же является основой для разработки комплекса количественных показателей деятельности организации в прошлом и будущем.
Предложенная ССП включает в себя четыре составляющие: клиенты, финансы, персонал (обучение и развитие) и внутренние бизнес-процессы. ССП может
быть представлена так, как показано на рис. 1.4
35
Рис. 1.4. Схема ССП
Двунаправленные стрелки, идущие от компонента «Стратегия» к четырем
составляющим ССП, указывают на возможность корректировки стратегии организации при
изменении внутренних или внешних условий. Таким образом, подчеркивается, что ССП
позволяет не только оценивать деятельность корпорации, но и реализовывать стратегию.
Кроме того, это говорит о взаимосвязи всех показателей в достижении оптимального
баланса.
Каждая из четырех составляющих ССП, в свою очередь, включает в себя четыре модуля: цели, показатели, нормы и инициативы. Все модули должны иметь
соответствующее наполнение, для чего необходимо разработать цели и показатели
деятельности организации, установить нормы и определить приоритетности инициатив. Количественное внедрение ССП представлено в таблице.
ПОКАЗАТЕЛИ КОЛИЧЕСТВЕННОГО ВНЕДРЕНИЯ ССП
Организации,
внедрившие
оценку
деятельности, %
Организации,
не внедрившие
оценку
деятельности, %
Лидер отрасли в течение
последних трех лет
74
44
По финансовому рейтингу
входит в треть лучших
организаций своей отрасли
83
52
Успешная реализация
последней крупной
программы
97
55
Согласованность стратегии
93
37
Распространение
информации о стратегии
среди персонала
60
8
Показатель успеха
организации
36
ССП является инструментом, «с помощью которого тысячи организаций осуществляют перевод своей стратегии в показатели, обеспечивают единую направленность действий работников и реализуют потенциал сегодняшних создающих
стоимость нематериальных активов. Для изменения существующего положения
в лучшую сторону система показателей должна быть интегрирована в системы
управления вашей организации, став краеугольным камнем управленческого анализа, поддержки и процесса принятия решений».
В общем случае количественные показатели деятельности корпорации составляют две группы: итоговые показатели, оценивающие результат осуществленной деятельности, и опережающие показатели, прогнозирующие ее будущую деятельность.
Исходя из четырех составляющих ССП, в простейшем случае минимальное
количество показателей будет равно 8. Если учитывать динамику развития современного рынка, то целесообразно иметь как минимум два опережающих показателя на каждую составляющую. Тогда минимальное количество показателей будет
равно 12. Большинство специалистов-практиков и консультантов по системе показателей придерживаются мнения, что сбалансированная система для высшего
уровня в организации требует от 20 до 25 показателей. Рекомендуемое эталоном
количество и распределение показателей по составляющим ССП следующее:
• финансы
• клиенты
• оптимизация бизнес-процессов
• кадровое обеспечение
3–4
5–8
5–10
3–6
Общее же количество показателей всех уровней в организации может составлять сотни и даже тысячи. Это определяется возможностью их отслеживания и обработки соответствующей информации.
1.9. КОНТРОЛЬНЫЕ ВОПРОСЫ
1. Дать определение концепции CALS.
2. Проблема философии проектирования.
3. Предпосылки создания CALS.
4. Стратегические цели CALS.
5. Основные показатели эффективности CALS.
6. Связь CALS с мировым рынком.
7. Развитие CALS за рубежом.
8. Основные разделы программы развития и внедрения CALS в России.
9. Стратегия развития CALS в России.
10. Что такое сбалансированная система показателей?
37
2. РАЗРАБОТКА ИПИ-ТЕХНОЛОГИЙ
2.1. ПРОДУКТ И ЕГО ЖИЗНЕННЫЙ ЦИКЛ
Согласно международным стандартам качества продукции серии ISO 9000 изделием (в этих стандартах оно именуется «продуктом») является результат некоторой деятельности или выполненных процессов. Там же выделяются четыре категории продуктов:
• технические средства – осязаемый отдельный продукт определенной формы;
• программное обеспечение – интеллектуальное творение, состоящее из информации, выражаемой с помощью обеспечивающих средств;
• обработанные материалы – осязаемый продукт, являющийся результатом
преобразования сырья в желаемое состояние;
• услуги – итоги непосредственного взаимодействия поставщика и потребителя и внутренней деятельности поставщика по удовлетворению потребностей потребителя.
В этих же стандартах вводится понятие жизненного цикла продукта, т. е. совокупности процессов, выполняемых от момента выявления потребностей общества в определенном продукте до момента удовлетворения этих потребностей
и утилизации продукта.
Можно выделить 11 этапов ЖЦ продукта (некоторые из этих этапов могут
выполняться по несколько раз и/или пересекаться с другими этапами ЖЦ):
• маркетинг и изучение рынка;
• проектирование и разработка продукта;
• планирование и разработка процессов (технологий производства, эксплуатации и т. п.);
• закупка материалов и комплектующих;
• производство или предоставление услуг;
• упаковка и хранение;
• реализация;
• монтаж и ввод в эксплуатацию;
• техническая помощь и сервисное обслуживание;
• послепродажная деятельность или эксплуатация;
• утилизация и переработка в конце полезного срока службы.
На всех этапах жизненного цикла имеются свои целевые установки. При этом
участники жизненного цикла стремятся достичь поставленных целей с максимальной эффективностью. На этапах проектирования, технологической подготовки
производства (ТПП) и производства нужно обеспечить выполнение требований,
предъявляемых к производимому продукту, при заданной степени надежности изделия и минимизации материальных и временных затрат, что необходимо для достижения успеха в конкурентной борьбе в условиях рыночной экономики. Понятие
эффективности охватывает не только снижение себестоимости продукции и сокращение сроков проектирования и производства, но и обеспечение удобства освоения и снижения затрат на будущую эксплуатацию изделий. Особую важность
38
требования удобства эксплуатации имеют для сложной техники, например в таких
отраслях, как авиа- или автомобилестроение.
ЖЦ обычно составляет от нескольких до десятков лет, причем довольно
большую часть этого времени занимают периоды разработки и изготовления
(рис. 2.1).
Рис. 2.1. Жизненный цикл изделия
Достижение поставленных целей на современных предприятиях, выпускающих сложные технические изделия, оказывается невозможным без широкого использования автоматизированных систем (АС), основанных на применении компьютеров и предназначенных для создания, переработки и использования всей необходимой информации о свойствах изделий и сопровождающих процессов.
Специфика задач, решаемых на различных этапах жизненного цикла изделий, обусловливает разнообразие применяемых АС.
На рис. 2.2 указаны основные типы АС с их привязкой к тем или иным этапам
жизненного цикла изделий.
Рассмотрим содержание основных этапов ЖЦИ для изделий машиностроения.
Цель маркетинговых исследований – анализ состояния рынка, прогноз спроса
на планируемые изделия и развития их технических характеристик.
На этапе проектирования выполняются проектные процедуры – формирование принципиального решения, разработка геометрических моделей и чертежей,
расчеты, моделирование процессов, оптимизация и т.п. Этап проектирования
включает все необходимые стадии, начиная с внешнего проектирования, выработки концепции (облика) изделия и кончая испытаниями пробного образца или партии изделий. Внешнее проектирование обычно включает разработку технического
и коммерческого предложений и формирование технического задания (ТЗ) на основе результатов маркетинговых исследований и/или требований, предъявленных
заказчиком.
39
Рис. 2.2. Этапы жизненного цикла промышленной продукции
и используемые автоматизированные системы
На этапе подготовки производства разрабатываются маршрутная и операционная технологии изготовления деталей, реализуемые в программах для станков
ЧПУ; технология сборки и монтажа изделий; технология контроля и испытаний.
На этапе производства осуществляются: календарное и оперативное планирование, приобретение материалов и комплектующих с их входным контролем, механообработки и другие требуемые виды обработки, контроль результатов обработки, сборка, испытания и итоговый контроль.
На постпроизводственных этапах выполняются консервация, упаковка, транспортировка, монтаж у потребителя, эксплуатация, обслуживание, ремонт, утилизация.
Основная проблема создания современного конкурентоспособного изделия –
управление процессами ЖЦ изделия на всех его этапах. Задача сводится к сокращению сроков производства и увеличению срока эксплуатации.
Традиционный подход, сложившийся в первоначальный период внедрения
вычислительной техники в производственные процессы, состоял в том, что с ее
помощью решались отдельные, частные задачи, относившиеся к различным стадиям ЖЦ изделий. Исторически первыми здесь были задачи, позволяющие автоматизировать отдельные учетно-управленческие функции в рамках так называемой автоматизированной системы управления производством (АСУП).
Почти одновременно с ними появились автоматизированные системы управления технологическими процессами (АСУ ТП). Затем стали разрабатываться
и внедряться системы автоматизированного проектирования (САПР), которые позволяли использовать средства вычислительной техники в процессах конструкторской и технологической подготовки производства.
40
Первые из них называют системами расчетов и инженерного анализа или системами CAE. Системы конструкторского проектирования называют системами
CAD. Проектирование технологических процессов выполняется в автоматизированных системах технологической подготовки производства (АСТПП), входящих
как составная часть в системы CAM.
Для решения проблем совместного функционирования компонентов САПР
различного назначения, координации работы систем CAE/CAD/CAM, управления
проектными данными и проектированием разрабатываются системы, получившие
название систем управления проектными данными PDM (Product Data
Management).
По мере увеличения числа таких систем на предприятиях возникла проблема
передачи информации между ними, что естественным образом привело к идее информационной интеграции и, как следствие, созданию ЕИП. Материальное воплощение ЕИП – интегрированная информационная среда, объединяющая системы:
• управление маркетингом;
• САПР;
• АСТПП;
• управление качеством;
• АСУП;
• др. системы.
Несмотря на все изменения на мировом рынке наукоемких промышленных
изделий, основная задача, стоящая перед любым предприятием, осталась прежней – повышение конкурентоспособности своих изделий. Конкурентоспособность
условно можно представить в виде дроби (см. ниже), в числителе которой находится степень удовлетворения потребностей заказчика изделия, а в знаменателе –
издержки предприятия при удовлетворении потребностей заказчика. Таким образом, повышать конкурентоспособность изделия необходимо двумя путями.
Степень удовлетворения потребностей заказчика:
• повышение степени удовлетворения потребностей
Конкурентоспособность =
заказчика.
Издержки:
• сокращение времени выхода изделия на рынок;
• сокращение материальных затрат.
Во-первых, необходимо повысить степень удовлетворения потребностей заказчика изделия. Под этим подразумевается не только создание изделия с требуемыми функциональными характеристиками, но и соответствующие потребностям
услуги по поставке, эксплуатации, обслуживанию, ремонту и модернизации изделия. Одним из основных способов решения данной подзадачи является участие
заказчика в процессе создания изделия, включающее не только совместное определение требований к изделию, но и тесный контакт с заказчиком при проектировании, производстве и испытаниях изделия. Только так можно наиболее полно
41
удовлетворить потребности заказчика. Например, в США во всех проектах последних лет по разработке военных самолетов полноправным участником являются ВВС США, выступающие в качестве основного заказчика разрабатываемых изделий.
Во-вторых, необходимо снизить издержки, возникающие в результате удовлетворения предприятием потребностей заказчика. Основными путями снижения
этих издержек являются сокращение времени выхода изделия на рынок (т. е. сокращение временных издержек) и сокращение затрат на создание и эксплуатацию
изделия (т. е. сокращение материальных издержек).
Основной способ повышения конкурентоспособности изделия – повышение
эффективности процессов ЖЦ изделия:
• повышение эффективности управления материальными ресурсами;
• повышение эффективности управления финансовыми ресурсами;
• повышение эффективности управления кадровыми ресурсами;
• повышение эффективности управления информационными ресурсами, т. е.
все ресурсы можно условно разделить на четыре группы:
• материальные;
• финансовые;
• кадровые;
• информационные.
В настоящий момент разработано множество всевозможных методик повышения эффективности управления тем или иным видом ресурсов. Наиболее известными среди них являются:
• TQM (Total Quality Management) – тотальное управление качеством;
• MRP (Material Requirements Planning) – управление потребностью в материалах. Производственное планирование и инвентаризация, необходимые для эффективного управления процессами производства изделия. MRP-системы помогают достичь следующих целей одновременно:
– проверить, что материалы и изделия доступны для производства или доставки заказчикам,
– управлять наименьшим возможным уровнем инвентаризации,
– планировать производственные процессы, поставки и закупки.
На входе таких систем задается основной производственный план (см. MSP),
данные о запасах (информация о доступности сырья и полуфабрикатов), спецификация материалов (см. BOM) и данные о планировании (маршрутные, трудовые
и машинные стандарты). На выходе получается рекомендованный производственный план (с детальной информацией о времени начала и окончания каждой операции в терминах компонентов изделия) и рекомендованный план закупок сырья
и полуфабрикатов. Возникшая в конце 1960-х гг. технология MRP затем была расширена до более общей технологии планирования производственных ресурсов
(см. MRP II) и концепции управления ресурсами предприятия (см. ERP);
• MRPII (Manufacturing Resource Planning) – управление производственными
ресурсами. Метод эффективного планирования всех ресурсов предприятияпроизводителя. Позволяет осуществлять операционное планирование (в единицах
42
продукции), финансовое планирование (в долларах) и моделировать различные
ситуации, отвечая на вопросы «что если». Состоит из набора взаимосвязанных
функций, основными из которых являются:
– бизнес-планирование,
– планирование производства и продаж,
– планирование выпуска продукции,
– составление основного производственного плана (см. MSP),
– планирование потребности в материалах (см. MRP),
– планирование потребности в производственных мощностях (см. CRP),
– системы поддержки управления производственными мощностями и материалами.
Американское общество по контролю над производством и запасами
(American Production and Inventory Control Society, APICS) разработало стандарт
MRP II, который включает в себя детальное описание 16 групп основных функций.
Интегрированные финансовые отчеты, получаемые с помощью систем класса MRP
II, содержат следующую информацию:
– бизнес-план,
– отчет обязательств по заказам,
– экспедиторский бюджет,
– цена запасов в долларах.
• ERP (Enterprise Resource Planning) – планирование (управление) ресурсов
предприятия. Данный термин появился в результате развития концепции планирования производственных ресурсов (см. MRP II). ERP-системы – это информационные управляющие системы, которые интегрируют и объединяют множество бизнес-процессов, связанных с операционными или производственными аспектами
предприятия:
– производство,
– логистика,
– дистрибуция,
– складирование,
– погрузка,
– выставление счетов,
– бухучет.
ERP-системы зачастую используются совместно с автоматизированными системами управления производственными процессами (см. MES). ERP-системы часто называются системами класса бэк-офис, чтобы отделить их от фронт-офис систем, таких как системы управления взаимодействия с клиентами (см. CRM) или
системы управления цепочками поставок (см. SCM). В более широкой трактовке
термин ERP включает в себя системы классов MRP II, HRM, SCM и CRM.
• SCM (Supply Chain Management) – управление цепочками поставок. Цепь
поставок обычно определяют как совокупность стадий увеличения добавленной
стоимости продукции при ее движении от компаний-поставщиков к компаниямпотребителям. Процесс планирования, осуществления и контроля операций в цепи
43
или сети поставок, логистической сети, основная цель которого – удовлетворить
требования заказчика максимально эффективно. При планировании производства
система SCM управляет стратегией позиционирования продукции. Данная деятельность состоит в управлении всеми перемещениями и складированиями сырья,
полуфабрикатов и готовых изделий от пункта отправления до пункта потребления
товара. Если время производственного цикла меньше времени ожидания заказчика
на получение готовой продукции, то можно применять стратегию «изготовление
на заказ». Иначе приходится использовать стратегию «изготовление на склад».
При этом во время производственного цикла должно входить время на размещение
и исполнение заказов на необходимые материалы и комплектующие на предприятиях-поставщиках.
В рамках SCM успешно решаются следующие проблемы:
– конфигурация распределенной сети: количество и местоположение поставщиков, производственных мощностей, оптовых баз, складов и заказчиков;
– стратегия распространения товара: централизованная или децентрализованная, прямые поставки или стыковки, маркетинговая стратегия вытягивания или
вталкивания товаров на рынок (pull or push strategy), логистические услуги третьей
стороны;
– информация: интеграция систем и процессов во всей цепочке поставок для
разделения ценной информации, такой как сигналы о запросах, прогнозы, инвентаризация и транспортировка;
– управление инвентаризацией: количество и местоположение инвентаря,
включая сырье, полуфабрикаты и готовые изделия.
• CRM (Customer Relationship Management) – управление взаимодействием
с клиентом. Это бизнес-стратегия, ориентированная на нужды заказчика, состоящая в выстраивании отношений с клиентами с помощью специальных систем,
процессов и процедур взаимодействия. Система используется на этапах маркетинговых исследований и реализации продукции, с ее помощью выполняются функции управления отношениями с заказчиками и покупателями, проводится анализ
рыночной ситуации, определяются перспективы спроса на планируемые изделия.
CRM-система – это корпоративная информационная система, предназначенная для улучшения обслуживания клиентов путем сохранения информации о клиентах и истории взаимоотношений с клиентами, установления и улучшения бизнес-процедур на основе сохраненной информации и последующей оценке их эффективности. Ее основные принципы таковы:
– наличие единого хранилища информации, откуда в любой момент доступны
все сведения обо всех случаях взаимодействия с клиентами,
– синхронизированость управления множественными каналами взаимодействия (т. е. существуют организационные процедуры, которые регламентируют использование этой системы и информации в каждом подразделении компании),
– постоянный анализ собранной информации о клиентах и принятии соответствующих организационных решений, например приоритизации клиентов на основе их значимости для компании.
44
Таким образом, этот подход подразумевает, что при любом взаимодействии
с клиентом по любому каналу сотруднику организации доступна полная информация обо всех взаимоотношениях с клиентами и решение принимается на ее основе,
информация о котором, в свою очередь, тоже сохраняется и доступна при всех последующих взаимодействиях. Системы управления взаимодействия с клиентами
иногда рассматриваются как часть ERP (при широком толковании термина
«управление ресурсами предприятия», см. ERP);
• CRP (Capacity Requirements Planning) – планирование потребности в производственных мощностях. Технология планирования загрузки трудовых и технических ресурсов в соответствии с заданным планом потребностей в материалах
(см. MRP). Загрузка рабочих мест рассчитывается на основе технологического
маршрута изготовления изделия – набора шагов (операций), которые необходимо
совершить для изготовления изделия или его части. Каждая операция совершается
на каком-то рабочем месте, которое может состоять из одного или нескольких человек и/или оборудования. Технология CRP является частью концепции планирования производственных ресурсов (см. MRP II);
• MES (Manufacturing Execution System) – автоматизированная система управления производственными процессами. MES-система позволяет контролировать
процессы, материалы, трудовые ресурсы в реальном времени. Как правило, данная
система состоит из большого числа аппаратных и программных устройств. MESсистема тесно взаимодействует с ERP-системой, получая из нее производственные
планы, составленные с учетом заказов и поставок сырья, и передавая назад информацию о реальных затратах на всех этапах производства партии;
• MPM (Manufacturing Process Management) – управление производственными
процессами, цифровое производство (digital manufacturing). Обобщенное название
набора технологий, методов и программ, используемых при производстве изделий.
MPM является ключевым элементом концепции управления жизненным циклом
изделий, являясь связующим звеном между системами проектирования (см. CAD)
и системами планирования ресурсов предприятия (см. ERP). Планирование производственных цехов (см. AEC), технологических процессов (см. CAPP), программирование станков с ЧПУ (см. CAM и CNC) являются компонентами MPM. Система
MPM тесно взаимодействует с системами управления данными об изделии
(см. PDM), планирования ресурсов предприятия (см. ERP) и автоматизированной
системой управления производственными процессами (см. MES);
• MPS (Master Production Schedule) – основной производственный план. Комбинация всех известных и ожидаемых потребностей в определенном продукте.
Производственный план простирается до горизонта планирования – несколько месяцев или лет в будущее – и содержит в себе только данные о потребности в конечных изделиях во времени. Уровень компонентов (потребностей в компонентах)
обрабатывается системами планирования потребности в материалах (см. MRP);
• HRM (Human Resource Management) – управление персоналом (кадрами)
с помощью интеллектуальных технологий. Обычно HRM-системы поддерживают
следующий набор функциональных модулей:
45
– составление платежных ведомостей,
– контроль рабочего времени и вида исполняемых работ,
– управление системой льгот (контроль медицинских страховок, пенсионных
отчислений, участия в разделе прибыли компании, опционы на акции компании),
– собственно управление персоналом (информация о возрасте, семейном положении, месте проживания, квалификации, участии в проектах, прохождении
тренингов).
Системы управления персоналом часто интегрируются в большие системы
управления ресурсами предприятия (см. ERP), где они играют взаимодополняющую роль с модулями финансового планирования и планирования потребностей
в производственных мощностях (см. CRP).
В последнее время усилия многих компаний, производящих программноаппаратные средства автоматизированных систем, направлены на создание систем
электронного бизнеса (E-commerce). Задачи, решаемые системами E-commerce,
сводятся не только к организации на сайтах Internet витрин товаров и услуг. Они
объединяют в едином информационном пространстве запросы заказчиков и данные о возможностях множества организаций, специализирующихся на предоставлении различных услуг и выполнении тех или иных процедур и операций по проектированию, изготовлению, поставкам заказанных изделий. Проектирование непосредственно под заказ позволяет добиться наилучших параметров создаваемой
продукции, а оптимальный выбор исполнителей и цепочек поставок ведет к минимизации времени и стоимости выполнения заказа. Координация работы многих
предприятий-партнеров с использованием технологий Intrenet возлагается на системы E-commepce, называемые системами управления данными в интегрированном информационном пространстве CPC (Collaborative Product Commerce).
Управление в промышленности,
как и в любых сложных системах,
имеет иерархическую структуру. В общей структуре управления выделяют
несколько иерархических уровней,
показанных на рис. 2.3. Автоматизация управления на различных уровнях
реализуется с помощью автоматизированных систем управления (АСУ).
Информационная поддержка этапа производства продукции осуществляется автоматизированными системами
управления
предприятием
(АСУП) и автоматизированными системами управления технологическими
процессами (АСУТП).
Рис. 2.3. Общая структура управления
46
К АСУП относятся системы планирования и управления предприятием ERP,
планирования производства и требований к материалам MRP-2 и системы SCM.
В некоторых случаях системы SCM и MRP-2 входят как подсистемы в ERP, в последнее время их чаще рассматривают как самостоятельные системы.
Промежуточное положение между АСУП и АСУТП занимает производственная исполнительная система MES, предназначенная для решения оперативных задач управления проектированием, производством и маркетингом.
В состав АСУТП входит система SCADA (Supervisory Control and Data
Acquisition), выполняющая диспетчерские функции (сбор и обработка данных
о состоянии оборудования и технологических процессов) и помогающая разрабатывать ПО для встроенного оборудования. Для непосредственного программного
управления технологическим оборудованием используют системы CNC на базе
контроллеров (специализированных компьютеров, называемых промышленными),
которые встроены в технологическое оборудование с числовым программным
управлением (ЧПУ). Системы CNC называют также встроенными компьютерными
системами.
Функции обучения обслуживающего персонала выполняют интерактивные
электронные технические руководства (ИЭТР, IETM – Interactive Electronic
Technical Manuals). С их помощью выполняются диагностические операции, поиск
отказавших компонентов, заказ дополнительных запасных деталей и некоторые
другие операции на этапе эксплуатации систем.
Таким образом, основная проблема создания современного конкурентоспособного изделия – управление процессами ЖЦ изделия на всех его этапах. Задача
сводится к сокращению сроков производства и увеличению срока эксплуатации.
Среди этих методик повышения эффективности процессов ЖЦ изделия особо
следует выделить CALS-технологии, направленные, в первую очередь, на повышение эффективности управления информационными ресурсами предприятия.
Было бы неправильно считать CALS панацеей при решении всех проблем предприятия.
В то же время CALS является одним из важнейших компонентов при решении
проблемы повышения конкурентоспособности промышленного изделия, который
необходимо использовать вместе с другими способами повышения эффективности
процессов ЖЦ.
2.2. КОНЦЕПЦИЯ CALS
Почему же информация является столь важным ресурсом предприятия? Дело
в том, что современное промышленное изделие состоит из двух равнозначных
компонентов: физического воплощения изделия («физический продукт») и информационного воплощения изделия («интеллектуальный продукт»), т. е. данных
об изделии. При этом физический продукт начинает появляться только на этапе
производства изделия и заканчивает существование на этапе утилизации изделия.
В то же время интеллектуальный продукт начинает свое существование вместе
47
с началом ЖЦ изделия (с этапа маркетинга и изучения рынка) и может продолжать
существовать (правда, в «замороженном» виде) даже после окончания ЖЦ изделия. На начальных этапах ЖЦ изделия (маркетинг, проектирование, разработка
процессов) интеллектуальный продукт тождественен самому изделию, т. к. физического продукта еще не существует в природе.
Целью концепции CALS является повышение эффективности управления информацией об изделии за счет преобразования ЖЦ изделия в высокоавтоматизированный процесс. Такой подход стал реальностью благодаря бурному развитию новых технологий обработки, хранения, доступа и передачи информации вне зависимости от способа ее представления, количества и местонахождения. Новые
информационные технологии, включающие технологии хранилищ данных, технологии обмена информацией в глобальных сетях, объектноориентированный подход, методы искусственного интеллекта, являются основным средством реализации концепции CALS.
2.3. КОНЦЕПТУАЛЬНАЯ МОДЕЛЬ CALS (ИПИ)
Согласно схеме (рис. 2.4) основу, ядро ИПИ составляет ИИС, или ЕИП.
В принципе, оба термина равнозначны, однако в терминологическом словаре, утвержденном Госстандартом России, принят первый термин, который в дальнейшем
используется. На практике термин ИИС используют в основном применительно
к конкретному предприятию, а ЕИП – применительно к виртуальному предприятию (консорциуму).
Упомянутый словарь определяет ИИС как совокупность распределенных баз
данных, содержащих сведения об изделиях, производственной среде, ресурсах
и процессах предприятия, обеспечивающая корректность, актуальность, сохранность и доступность данных тем субъектам производственно-хозяйственной деятельности, участвующим в осуществлении ЖЦ изделия, кому это необходимо
и разрешено. Все сведения (данные) в ИИС хранятся в виде информационных объектов. В ИИС действует единая система правил представления, хранения и обмена
информацией.
В ИИС протекают информационные процессы, сопровождающие и поддерживающие ЖЦ изделия на всех его этапах. Здесь реализуется главный принцип ИПИ:
информация, однажды возникшая на каком-либо этапе ЖЦ, сохраняется в ИИС
и становится доступной всем участникам этого и других этапов (в соответствии
с имеющимися у них правами пользования этой информацией). Это позволяет избежать дублирования, перекодировки и несанкционированных изменений данных,
избежать связанных с этими процедурами ошибок и сократить затраты труда, времени и финансовых ресурсов.
Основное содержание ИПИ, принципиально отличающее эту концепцию
от других, составляют инвариантные понятия, которые реализуются (полностью
или частично) в течение ЖЦ изделия.
48
Рис. 2.4. Концептуальная модель CALS (ИПИ)
Эти инвариантные понятия условно делятся на две группы:
• основные ИПИ-принципы;
• базовые ИПИ-технологии.
К числу первых относятся:
• анализ и реинжиниринг бизнес-процессов (Business-processes analysis and reengineering);
• безбумажный обмен данными (Paperless Data interchange) с использованием
ЭЦП;
• параллельный инжиниринг (Concurrent Engineering);
• системная организация постпроизводственных процессов ЖЦ изделия (интегрированная логистическая поддержка – ИЛП, ILS – Integrated Logistic Support).
Необходимо выделить принцип параллельного инжиниринга, означающего
выполнение процессов разработки и проектирования одновременно с моделированием процессов изготовления и эксплуатации. Сюда же относится одновременное
проектирование различных компонентов сложного изделия. При параллельном
инжиниринге многие проблемы, которые могут возникнуть на более поздних стадиях ЖЦ, выявляются и решаются на стадии пректирования. Такой подход позволяет улучшить качество изделия, сократить время его вывода на рынок, сократить
затраты.
Параллельный инжиниринг отличается от традиционного подхода следующими моментами:
49
• ликвидацией традиционных барьеров между отдельными функциями отдельных специалистов и организаций путем создания, а при необходимости последующего преобразования, многопрофильных рабочих групп, в том числе территориально распределенных;
• итеративностью процесса приближения к необходимому результату.
Многопрофильные рабочие группы (МПГ), как следует из их названия, включают специалистов разного профиля и создаются для решения конкретных задач.
Например, представители эксплуатанта, генерального разработчика и поставщика
комплектующих изделий, т. е. специалисты из разных организаций, могут быть
собраны в одну МПГ для решения проблемы, возникающей в ходе эксплуатации.
Параллельный инжиниринг предполагает замену традиционного последовательного подхода комплексом перекрывающихся во времени операций, направленных на систематическое улучшение разрабатываемого решения вплоть до достижения необходимого результата.
Исходное понимание задачи ведет к первой версии документированных требований, на основе которых разрабатывается первоначальное проектное решение.
Оно порождает новые вопросы и позволяет уточнить постановку задачи. Поскольку жесткое требование завершить текущую фазу работы перед началом следующей
отсутствует, последовательное проектирование заменяется «работой по спирали».
Эффективная реализация такого подхода невозможна вне интегрированной
информационной среды. Возможность применения принципа параллельного инжиниринга возникает благодаря тому, что в ИИС все результаты представлены
в электронном виде, являются актуальными, доступны всем участникам и легко
могут быть скорректированы.
Другие основные ИПИ-принципы будут рассмотрены ниже.
К числу вторых инвариантных понятий относятся:
• управление проектом (Project Management);
• управление данными об изделии (Product Data Management);
• управление конфигурацией изделия (Configuration Management);
• управление ИИС, в том числе информационными потоками (Information
Management);
• управление качеством (Quality Management);
• управление потоками работ (Workflow Management);
• управление изменениями производственных и организационных структур
(Change Management).
ИПИ-технологии реализуются силами многопрофильных рабочих групп, объединяющих в своем составе экспертов различных специальностей. В ИИС информация создается, преобразуется, хранится и передается от одного участника ЖЦ
к другому при помощи программных средств, объединенных на схеме (см. рис. 2.4)
в блок «Инструментарий». К числу таких средств относятся:
• автоматизированные системы конструкторского и технологического проектирования (CAE/CAD/CAM);
• программные средства управления данными об изделии (изделиях) (PDM);
50
• автоматизированные системы планирования и управления производством
и предприятием (MRP/ERP);
• программно-методические средства анализа логистической поддержки и ведения баз данных по результатам такого анализа (LSA/LSAR);
• программные средства управления потоками работ (WF);
• методология и программные средства моделирования и анализа бизнеспроцессов (SADT) и др.
Следующие критерии определяют принадлежность конкретной информационной системы к классу ИПИ-систем:
• обязательное наличие на предприятии ИИС;
• системная реализация инвариантных принципов и технологий ИПИ;
• применение прикладных программных средств, изначально ориентированных на взаимодействие через ИИС;
• использование методов, правил и способов управления, изначально ориентированных на безбумажный обмен данными через ИИС;
• реализация принципов, технологий и процессов информационного взаимодействия в соответствии с требованиями международных и национальных стандартов (например, ISO 10303 и ГОСТ РИСО 10303).
Системы, не удовлетворяющие перечисленным критериям, не следует относить к классу ИПИ-систем. Такие системы обеспечивают лишь фрагментарную
(«лоскутную») автоматизацию со всеми присущими этой стратегии недостатками.
2.4. ИНТЕГРИРОВАННАЯ ИНФОРМАЦИОННАЯ СРЕДА ПРЕДПРИЯТИЯ
2.4.1. ОБЩЕЕ ПОНЯТИЕ О ИИС
Ядром ИПИ-технологий и создаваемых на этой основе автоматизированных
систем является ИИС.
Представление об ИИС было введено в научный обиход задолго до появления
CALS (ИПИ)-технологий. Еще в 1983 г. японский ученый Н. Окино опубликовал
работу, в которой утверждал, что производство материальных объектов и сопутствующие ему процессы проектирования, технологической подготовки и управления так сильно отличаются от других видов деятельности человека, что им
должна отвечать особая архитектура математического и информационного
обеспечения. По мнению Н. Окино, принципиальная разница между обработкой
информации в производственной системе и в других случаях применений вычислительной техники в основном сводится к двум положениям.
Производство и все процессы в нем принадлежат физическому миру, а процессы, протекающие в компьютере, – миру информации. Следовательно, необходимо преобразование производственных проблем в информационные, а также обратный переход из информационного мира в физический. По сути, это проблема
адекватного моделирования, т. е. установления соответствия (по возможности взаимно однозначного) между физическим и информационным пространством.
При создании традиционного математического обеспечения (МО) для решения
51
вычислительных задач в центр разработки ставится единственная математическая
модель проблемы, которая через прикладной интерфейс адаптируется к различным
областям применения (рис. 2.5). Такой подход к решению производственных проблем практически не реализуем, поскольку ввиду их сложности и многообразия
единую модель создать невозможно.
В связи с отмеченными выше недостатками традиционного подхода, основанного на схеме рис. 2.5, предлагается отбросить стратегию единственной модели
и перейти к стратегии, сущность которой
показана на рис. 2.6.
Здесь роль ядра системы играет
не модель, а общая (интегрированная) база
данных (ОБД), к которой могут обращаться
различные модели, реализованные в форме
программных приложений. Предполагается,
что в ОБД хранятся информационные объРис. 2.5. Схема создания
екты
(ИО), адекватно отображающие в интрадиционного МО
формационном мире сущности физического
мира: предметы, материалы, изделия, процессы и технологии, разнообразные документы, финансовые ресурсы, персонал подразделения и оборудование предприятия-изготовителя, эксплуатанта, сервисной и ремонтной служб и т. д.
Рис. 2.6. Схема создания МО на базе ОБД
52
Дальнейшее развитие ИТ привело к появлению объектно-ориентированного
подхода, который позволил адекватно перевести многие процессы, протекающие
на предприятии, в виртуальное информационное пространство, что и сделало актуальной всю проблематику, связанную с использованием ИПИ-технологий.
Сказанное относится, в частности, к процессам конструкторской и технологической подготовки производства, в ходе которых создается техническая документация различных видов и назначения; к процессам управления на всех уровнях,
в которых по необходимости приходится иметь дело с большими объемами разнообразной информации. Сегодня эти процессы в значительной мере состоят из операций создания, преобразования, транспортировки и хранения информационных
объектов в рамках ИИС.
2.4.2. СТРУКТУРА И СОСТАВ ИИС
Как уже отмечалось, ИИС представляет собой хранилище данных, содержащее все сведения, создаваемые и используемые всеми подразделениями и службами предприятия – участниками ЖЦ изделия – в процессе их производственной
деятельности. Это хранилище имеет сложную структуру и многообразные внешние и внутренние связи. ИИС должна включать в свой состав две базы данных:
общую базу данных об изделии (изделиях) (ОБДИ) и общую базу данных о предприятии (ОБДП).
На рис. 2.7. представлена структура ИИС во взаимодействии с процессами
ЖЦ продукции предприятия. Из схемы видно, что в этих процессах используется
информация, содержащаяся в ИИС, а ИО, порождаемые в ходе процессов, возвращаются в ИИС для хранения и последующего использования в других процессах.
Это отображено на схеме двойными стрелками. С ОБДИ связаны процессы на всех
стадиях ЖЦ изделия. ОБДП информационно связана с технологической и организационно-экономической подготовкой производства и собственно производством
(включая процессы отгрузки и транспортировки готовой продукции).
При создании нового изделия и технологической подготовке его производства
средствами конструкторских и технологических САПР (CAE/CAD/CAM) в ИИС
создаются ИО, описывающие структуру изделия, его состав и все входящие компоненты: детали, подузлы, узлы, агрегаты, комплектующие, материалы и т. д. Каждый ИО обладает атрибутами, описывающими свойства физического объекта:
технические требования и условия, геометрические (размерные) параметры, массогабаритные показатели, характеристики прочности, надежности, ресурса и другие
свойства изделия и его компонентов.
ИО в составе ОБДИ содержат в произвольном формате информацию, требуемую для выпуска и поддержки технической документации, необходимой на всех
стадиях ЖЦ для всех изделий, выпускаемых предприятием. Каждый ИО идентифицируется уникальным кодом и может быть извлечен из ОБДИ для выполнения
действий с ним. ОБДИ обеспечивает информационное обслуживание и поддержку
деятельности:
53
• заказчиков (владельцев) изделия;
• разработчиков (конструкторов), технологов, управленческого и производственного персонала предприятия-изготовителя;
• эксплуатационного и ремонтного персонала заказчика и специализированных служб.
Рис. 2.7. Структура ИИС во взаимодействии с процессами ЖЦ продукции
предприятия (см. также с. 55)
54
Рис. 2.7. Окончание
Более подробно состав ИО, входящих в ОБДИ, раскрыт на схеме рис. 2.8, согласно которой в составе ОБДИ можно условно выделить три раздела: нормативно-справочный; долговременный; актуальный.
55
Рис. 2.8. Состав ИО, входящих в ОБДИ
56
В нормативно-справочном разделе должны храниться ИО, содержащие
данные:
• о конструкционных материалах;
• о нормализованных деталях (нормалях);
• о стандартных (покупных) комплектующих изделиях;
• о стандартных деталях собственного изготовления;
• о стандартных расчетных методах;
• о государственных, международных и внутренних стандартах;
• о прочих нормативных документах.
Содержание нормативно-справочного раздела ОБДИ обновляется по мере поступления новых и отмены действующих нормативных документов.
В долговременном разделе должны храниться ИО, содержащие данные, аккумулирующие собственный опыт предприятия, в том числе данные:
• о ранее выполненных готовых проектах (архив);
• о типовых узлах и агрегатах собственного производства;
• о типовых деталях собственного производства;
• о типовых конструктивно-технологических элементах (КТЭ) деталей;
• о типовых и групповых технологических процессах;
• о типовой технологической оснастке и инструменте;
• о готовых и типовых расчетных методиках и математических моделях изделий собственной разработки;
• прочих готовых и типовых решениях.
Долговременный раздел ОБДИ дополняется и обновляется по мере появления
новых технических решений, признанных типовыми и пригодными для дальнейшего использования.
В актуальном разделе (по-видимому, самом большом по объему и самом
сложном по структуре) должны храниться ИО, содержащие данные об изделиях,
находящихся на различных стадиях ЖЦ:
• о конструкции и версиях текущих изделий;
• о технологии изготовления изделий;
• о конкретных экземплярах и партиях изделий в производстве;
• о конкретных экземплярах и партиях изделий, находящихся на постпроизводственных стадиях ЖЦ.
Структура этого раздела на рис. 2.8 весьма приблизительна и требует развития
и уточнения, в том числе разбивки на дополнительные подразделы (классификационные уровни).
Как уже отмечалось, кроме ИО, относящихся (прямо или косвенно) к изделиям, в ИИС содержится информация о предприятии: производственной и управленческой структуре, технологическом и вспомогательном оборудовании, персонале, финансах и т. д. Вся совокупность этих данных образует ОБДП, которая также состоит
из нескольких разделов: экономика и финансы, внешние связи предприятия, производственно-технологическая среда предприятия, система качества.
57
В разделе, посвященном экономике и финансам, должны храниться ИО, содержащие сведения:
• о конъюнктуре рынка изделий предприятия, включая цены и их динамику;
• о состоянии финансовых ресурсов предприятия;
• о ситуации на фондовом и финансовом рынках (курсы акций предприятия,
биржевые индексы, процентные ставки, валютные курсы и т. д.);
• о реальном и прогнозируемом портфеле заказов;
прочие сведения финансово-экономического и бухгалтерского характера.
В разделе, посвященном внешним связям предприятия, должны храниться
ИО, содержащие сведения о фактических и возможных поставщиках и потребителях (заказчиках); раздел формируется и используется в процессе маркетинговых
исследований.
В разделе, посвященном производственно-технологической среде предприятия, должны храниться ИО, содержащие сведения:
• о производственной структуре предприятия;
• о технологическом, вспомогательном и контрольно-измерительном оборудовании;
• о транспортно-складской системе предприятия;
• об энерговооруженности предприятия;
• о кадрах;
• прочие данные о предприятии.
В разделе, посвященном системе качества, должны храниться ИО, содержащие сведения:
• о структуре действующей на предприятии системы качества;
• о действующих на предприятии стандартах по качеству;
• о международных и российских стандартах по качеству;
• о должностных инструкциях в области качества;
• прочая информация по системе качества.
Из ИИС могут быть извлечены разнообразные документы, необходимые для
функционирования предприятия. Документы могут быть представлены как в электронном, так и в традиционном бумажном виде.
2.4.3. УПРАВЛЕНИЕ ИИС
Это понятие предполагает, что все процессы, протекающие в ИИС, являются
управляемыми, т. е. поддаются воздействиям со стороны уполномоченных лиц
и соответствующих программных средств. Совокупность таких средств принято
называть системой управления базами данных (СУБД). Традиционно в СУБД
входит:
• помещение информации в базу данных (БД);
• хранение информации (в том числе резервных копий);
• обновление данных;
• обеспечение достоверности и целостности данных;
• поиск данных по различным признакам;
• создание отчетов;
• установление (изменение) и оперативная проверка прав доступа пользователей к данным и т. д.
58
Распределенный характер ИИС, в отличие от традиционных БД, требует создания специальной инфраструктуры, обеспечивающей накопление, хранение и передачу данных между всеми заинтересованными участниками ЖЦ. Такая инфраструктура должна представлять собой комплекс программных и аппаратных
средств, позволяющий решать перечисленные выше задачи. В рамках традиционного предприятия, расположенного на единой (и единственной) производственной
площадке, такая инфраструктура создается на основе локальной вычислительной
сети и соответствующего системного и прикладного программного обеспечения.
Вопросы создания таких структур широко освещены в специальной литературе
и здесь не рассматриваются. Для предприятий, имеющих географически распределенную производственную структуру, и, в особенности, для виртуальных предприятий эта проблема играет важнейшую роль.
Анализ сегодняшнего состояния телекоммуникационных средств и систем позволяет высказывать утверждение, что основой инфраструктуры виртуального
предприятия, а также предприятия с географически распределенной структурой
может служить глобальная сеть Интернет, в которой данные передаются с помощью протокола TCP/IP. Использование этой сети в качестве структурообразующего средства связано с рядом специфических проблем.
Первая из этих проблем состоит в том, что для эффективного накопления,
хранения и использования данных всеми участниками информационного обмена
в соответствии с технологиями ИПИ хранилище данных должно быть логически
локализовано в форме, которую в Интернет-технологиях принято называть порталом. Иными словами, должен быть создан специальный узел сети Интернет, предназначенный для информационного обслуживания предприятия, виртуального
предприятия или корпорации.
Вторая проблема связана с тем, что этот узел и, соответственно, участники
информационного обмена должны быть ограждены от вмешательства в этот обмен
посторонних лиц и организаций, даже при отсутствии у них какого-либо злого
умысла или враждебных интересов.
Наконец, третья проблема состоит в защите информации от несанкционированного доступа лиц и организаций, имеющих своей целью использование информации во враждебных целях.
Решение первой проблемы не представляет принципиальных трудностей
и требует лишь соответствующих финансовых, кадровых и административных ресурсов.
Что касается второй и третьей проблем, то решение их связано с использованием внешне сходных, но по сути глубоко различных средств. Сходство заключается в том, что и те, и другие средства относятся к системам криптографической
защиты, и, как следствие, в порядке применения, лицензирования и сертификации
соответствующих средств. Защита информации во всех аспектах является важнейшей государственной проблемой и требует значительных усилий как со стороны
разработчиков программно-методических и технических средств передачи данных,
так и со стороны администраторов и законодателей.
59
2.5. СОЗДАНИЕ ЕДИНОГО ИНФОРМАЦИОННОГО ПРОСТРАНСТВА (ЕИП)
2.5.1. ВИРТУАЛЬНЫЕ ПРЕДПРИЯТИЯ
Развитием концепции CALS в 90-х гг. стала концепция «Виртуального предприятия» (ВП) (рис. 2.9).
При создании виртуального предприятия необходимо учитывать следующее:
• ВП создается набором юридически независимых организаций для достижения
определенной цели (выполнения проекта), например для создания и продвижения на
рынок некоторого изделия (т. е. время жизни ВП равно времени жизни проекта);
• участники ВП предоставляют в распоряжение ВП определенную часть своих ресурсов, а планирование и использование этих ресурсов осуществляется всеми
участниками ВП исходя из интересов всего проекта;
• потребители изделия (особенно, стратегический заказчик) являются полноправными участниками ВП;
• ВП обладает гибкой организационной структурой, позволяющей в любой
момент времени включить в свой состав новых участников и интегрировать их
в процесс выполнения проекта.
Рис. 2.9. Виртуальное предприятие
Таким образом, виртуальное предприятие – это группа предприятий, объединенных на контрактной основе, не имеющих единой юридической организационной инфраструктуры, но связанных единой информационной инфраструктурой
с целью использования компьютерной поддержки жизненного цикла конкретного
изделия. Виртуальные предприятия создаются в сжатые сроки, эффективно функционируют (рис. 2.10) и распадаются по завершению совместного проекта. Одно
и то же предприятие может одновременно входить в состав нескольких виртуальных предприятий.
60
Рис. 2.10. Сотрудничество в рамках виртуального предприятия
Пример такой организации на основе модели изделия приведен на рис. 2.11.
С точки зрения аспектов управления информацией на виртуальном предприятии
наиболее важные проблемы формулируются в следующем виде:
• проблема создания распределенной компьютерной сети; поскольку виртуальное предприятие представляет собой группу компаний, каждая из которых располагает своей собственной сетью, рабочими станциями и серверами, то эти сети
должны быть ЛОГИЧЕСКИ интегрированы для того, чтобы функционировать как
единая локальная сеть;
• проблема разделения данных; поскольку виртуальные предприятия формируются по принципу, основанному на том, что входящие в него компании по отдельности располагают чем-то ценным для внесения в общее виртуальное предприятие, то во многих случаях эти ценности представляют собой опыт в форме
существующих данных и продуктов либо способность разрабатывать новые продукты;
• проблема сопровождения данных, поскольку индивидуальным компаниям,
входящим в состав виртуального предприятия, необходимо функционировать как
«единое» предприятие, то у них возникают вопросы по координации рабочих потоков и методологии принятия управленческих решений;
• проблема информационной интеграции.
61
Рис. 2.11. Принцип обмена информацией между виртуальными предприятиями,
основанный на модели изделия
Появление концепции виртуального предприятия уже оказало определяющее
влияние на структуру современных промышленных компаний. Так, она предопределила создание поистине супертранснациональных монополий (ABB, Boeing, Airbus, Intel и др.), которые установили контроль над более 75 % мирового рынка
в областях своей специализации.
Рис. 2.12. Управление информацией
62
Для эффективного накопления, хранения и использования данных (рис. 2.12)
всеми участниками информационного обмена в соответствии с технологиями
CALS должен быть создан специальный узел сети Интернет.
Наиболее полно идеи интеграции реализованы в американском проекте NIIIP
(National Industrial Information Infrastructure Protocols). Цели проекта NIIIP:
• сделать американские промышленные предприятия глобально конкурентоспособными через новую форму совместной автоматизации, которая поддерживает
формирование ВП;
• обеспечить технологии, которые позволят виртуальным участникам предприятия сотрудничать независимо от структур данных, процессов и компьютерных
сред;
• позволить компаниям в пределах ВП объединять затраты, навыки и доступ
на глобальные рынки всех участников;
• позволить ВП обеспечивать потребителей конкурентоспособными изделиями, услугами, рентабельными и своевременными решениями независимо от организации, географических или технических границ.
2.5.2. ОСНОВНЫЕ ПРОБЛЕМЫ ПРИ УПРАВЛЕНИИ ИНФОРМАЦИЕЙ
Среди проблем, возникающих при использовании сети Интернет в качестве
структурообразующего средства, необходимо выделить проблему управления информацией. На эффективное управление информацией об изделии влияет огромное
количество этой информации (информационный хаос), возникающее из-за:
• усложнения изделий,
• использования прикладных автоматизированных систем;
и коммуникационные барьеры между участниками ЖЦ изделия:
• временной;
• пространственный;
• организационный;
• междисциплинарный;
• выразительный.
Таким образом, с одной стороны происходит увеличение сложности самих
наукоемких промышленных изделий и объема данных, описывающих эти изделия.
С другой стороны, использование на отдельных этапах ЖЦ изделия автоматизированных систем (например, САПР) приводит не только к улучшению качества
выполнения этих этапов, но и к увеличению примерно на порядок объема информации, создаваемой на этом этапе.
Старые методы работы с информацией уже не справляются с увеличивающимся потоком данных, и возникают угрозы потери их полноты, целостности
и актуальности, что в конечном итоге приводит предприятие к информационному
хаосу.
Кроме того, процесс взаимодействия любых участников ЖЦ изделия (организаций между собой, или подразделений, или даже сотрудников отдельной организации) обязательно связан с передачей информации. Эффективность такого обмена
63
данными значительно влияет на качество и конкурентоспособность изделия, особенно в случае ВП. Недостаточная эффективность передачи информации между
участниками ЖЦ изделия связана с наличием, как сказано выше, коммуникационных барьеров между участниками:
• временного барьера, связанного с получением доступа к данным, созданным
предшествующим по времени процессом или этапом ЖЦ (например, передача
данных с этапа проектирования на этап производства);
• пространственного барьера, связанного с получением доступа к данным,
созданным в географически удаленной точке;
• организационного барьера, связанного с получением доступа к данным, созданным в другой организации (в частности, вопросы интеллектуальной собственности);
• междисциплинарного барьера, связанного с получением доступа к данным,
описывающим изделие с иной, чем у получателя данных, точки зрения (например,
получение технологом конструкторского описания изделия);
• выразительного барьера, связанного с получением доступа к данным, форма
описания которых непонятна для получателя данных (например, передача данных
между различными компьютерными системами, имеющими различный формат
представления информации).
Рис. 2.13. Стратегия CALS
64
Таким образом, основной стратегией CALS (рис. 2.13) является создание единого информационного пространства (ЕИП) для всех участников ЖЦ изделия,
включая потребителя изделия. Создание ЕИП позволит преодолеть информационный хаос и коммуникационные барьеры между участниками ЖЦ изделия. Это
приведет к повышению эффективности процессов ЖЦ и улучшению взаимодействия между его участниками. Результатом такого повышения станет снижение временных и материальных издержек в течение ЖЦ изделия и повышение степени
удовлетворения потребностей заказчика, а это, в свою очередь, неизбежно приведет к повышению конкурентоспособности изделия.
2.6. ЕДИНОЕ ИНФОРМАЦИОННОЕ ПРОСТРАНСТВО
Традиционный подход, сложившийся в первоначальный период внедрения
вычислительной техники в производственные процессы, состоял в том, что с ее
помощью решались отдельные, частные задачи, относившиеся к различным стадиям ЖЦ изделий. Для взаимодействия в рамках ЕИП необходимы стандартные интерфейсы взаимодействия, предназначенные для интеграции всех программных
систем, используемых участниками ЖЦ изделия. Поскольку программных систем
очень много, а также в силу необходимости быстрой интеграции в ЕИП их новых
версий (случай виртуального предприятия) интерфейсы взаимодействия необходимо согласовывать с международными стандартами.
ЕИП предполагает отказ от прямого взаимодействия и передачи данных между участниками ЖЦ. Все коммуникации между ними должны осуществляться через ЕИП, основными свойствами которого являются:
• Информация представлена в электронном виде, преимущества которого перед бумажным способом представления информации очевидны: большая эффективность создания, хранения, изменения и доступа к данным.
• ЕИП охватывает всю информацию, созданную об изделии любым участником ЖЦ на любом этапе ЖЦ.
• ЕИП выступает единственным источником данных для любого участника
ЖЦ, предоставляя (в соответствии с правами доступа) нужную информацию
в нужное время в нужном виде.
Для интеграции программно-аппаратных средств участников ЖЦ в ЕИП используются только международные, государственные и отраслевые стандарты,
поддерживаемые подавляющим большинством производителей прикладных систем. Эти стандарты регламентируют вопросы представления и обмена данными
об изделии, а также процессы взаимодействия прикладных систем между собой.
Для создания ЕИП используются существующие на предприятиях программно-аппаратные средства. Это означает, что предприятиям не нужно отказываться
от уже используемых прикладных систем и терять, таким образом, сделанные
в них инвестиции. Вопрос стоит только об адаптации этих систем к работе в рамках ЕИП.
ЕИП как схема взаимодействия между собой участников ЖЦ должно, в соответствии с бизнес-идеей непрерывного развития, улучшаться в течение ЖЦ
65
изделия, используя новейшие достижения в области вычислительной техники
и информационно-коммуникационных технологий жизненного цикла продукции.
На западных предприятиях создание ЕИП вызвало определенные проблемы,
связанные с необходимостью связать между собой множество несовместимых друг
с другом компьютерных систем, разработанных ранее для автоматизации локальных задач, возникающих в течение ЖЦ. Отечественные предприятия, уровень автоматизации которых не столь высок, как на Западе (многие процессы ЖЦ еще
не автоматизированы), могут избежать значительной части этих проблем. Этого
можно достичь за счет учета требований ЕИП при автоматизации отдельных процессов ЖЦ, что позволит относительно безболезненно интегрировать точечные
решения в рамках ЕИП.
Таким образом, российская стратегия CALS предусматривает двухэтапный
переход к ЕИП:
• автоматизацию отдельных процессов (или этапов) ЖЦ изделия и представление данных на них в электронном виде в соответствии с требованиями ЕИП;
• интеграцию автоматизированных процессов и относящихся к ним данных,
уже представленных в электронном виде, в рамках ЕИП.
Использование ЕИП дает предприятию (особенно виртуальному) следующие
преимущества:
• Обеспечение целостности данных. Все данные об изделии хранятся один раз
в логически единой модели данных, что позволяет легче организовать контроль
за ними.
• Минимум преобразований при переходе с одного этапа ЖЦ на другой. Данные, созданные на начальных этапах ЖЦ изделия, не теряются и могут быть использованы на последующих этапах. Более того, их хранение в единой модели изделия позволяет исключить повторный ввод данных при переходе с одного этапа
ЖЦ на другой, что значительно экономит время и снижает количество ошибок.
• Изменения данных видны всем и сразу. Если один из участников ЖЦ изменяет информацию о своей части изделия, то эти изменения становятся доступными
для других участников немедленно, что исключает ситуации, при которых возможна работа над устаревшей информацией.
• Повышение скорости поиска и доступа к данным. Электронное представление данных позволяет значительно сократить время, затрачиваемое на поиск необходимой информации и доступ к ней, по сравнению с бумажным документооборотом.
• Использование различных компьютерных систем для доступа к данным. Для
осуществления нормального обмена данными участники ЖЦ не должны использовать одинаковые компьютерные системы и множество конверторов для каждой
пары систем. Передача данных через ЕИП предполагает необходимость наличия
интерфейса только с ЕИП.
• Организация географически удаленного доступа к данным. Даже в случае,
когда участники ЖЦ территориально удалены друг от друга (например, в случае
виртуального предприятия), ЕИП позволяет обеспечить их функционирование
в единой среде.
66
Материальное воплощение ЕИП предприятия – интегрированная информационная система (ИИС) предприятия объединяет системы (рис. 2.14), автоматизирующие отдельные этапы ЖЦ:
• система управления маркетингом;
• САПР:
• АСТПП;
• система управления качеством;
• АСУП и др.
Последнее время Россия получила возможность использовать наиболее перспективные решения в создании «скелета» будущей системы управления. Такими
скелетообразующими направлениями стали инфраструктура производства продукции и технологии. На современном уровне задача создания «скелета» для описания
производственной деятельности решается на уровне ERP- и PDM-систем.
PDMприложения
Система
управления
качеством
АСУП
С ADсистемы
Другие
приложения
Связь с внешними
организациями
Управляемые файлы
PDM-система
Данные
в виде фа йлов
Рис. 2.14. Интегрированная информационная среда (основа ИИС – PDM-система)
ЕИП может быть создано для организационных структур разного уровня (таблица): от отдельного подразделения предприятия до корпорации. Соответственно,
разным может быть эффект, получаемый от создания ЕИП. В качестве критериев
для оценки эффекта от ЕИП можно рассматривать: повышение эффективности
управления данными и повышение эффективности обмена данными внутри организационной структуры.
Что касается повышения эффективности управления данными, то здесь во всех
случаях наблюдается большой эффект. Это объясняется большим количеством информации об изделии, создаваемом и используемом на всех уровнях.
67
УРОВНИ ЕИП
Организационная
структура
Подразделение
предприятия
Отдельное
предприятие
Виртуальное
предприятие
(корпорация)
Эксплуатирующая
организация
Повышение
эффективности
управления процессами
Повышение
эффективности
управления данными
Среднее
Высокое
Повышение
эффективности обмена
данными
внутри структуры
Низкое
Высокое
Высокое
Среднее
Высокое
Высокое
Высокое
Среднее
Высокое
Среднее
Среднее повышение эффективности управления процессами наблюдается там,
где количество и сложность процессов относительно невелики (эксплуатирующая
организация) и достаточно контролируемы (подразделение предприятия).
Повышение эффективности обмена данными незначительно в случае подразделения предприятия. Это объясняется тем, что в подразделении, скорее всего, либо используются одинаковые компьютерные системы, либо, в случае разнородных
систем, взаимодействие между ними уже налажено. На предприятии эта проблема
стоит более остро и ЕИП дает средний эффект (то же самое можно сказать и про
эксплуатирующую организацию). Наибольший же эффект в области эффективности обмена данными ЕИП приносит для виртуального предприятия (корпорации).
С позиций информационных технологий бизнес-процесс в общем случае может обеспечиваться функционированием трех систем:
• CRM (Customer Relationship Management – управление отношениями
с клиентами) – информационная система управления взаимодействием с заказчиком, который формирует требования к продукции;
• SCM (Supply Chain Management – управление цепочками поставок) – информационная система управления и оптимизации взаимодействия с поставщиками
в рамках необходимой кооперации по производству материального товара или оказанию услуг, которая планирует и контролирует поставки комплектующих
и выполнение работ внешними контрагентами;
• ERP (Enterprise Resource Planning) – информационная система эффективного планирования и управления всеми ресурсами предприятия, которые необходимы для производства материального товара или оказания услуг.
Рассмотрим эти системы, а соответственно, и бизнес-процессы, реализуемые
в них, с позиций жизненного цикла изделия, в котором выделим пять этапов:
• этап исследований (маркетинговые исследования, НИОКР и т. п.);
• этап разработки;
• этап подготовки производства;
• этап производства продукции (активных продаж);
• этап снятия с производства.
68
Можно заключить, что системы CRM управляют бизнес-процессами, связанными с начальными и конечными этапами жизненного цикла изделия – этапом исследований и этапом производства продукции. Системы SCM управляют бизнеспроцессами, расположенными в середине жизненного цикла изделия, – этапом
подготовки производства и этапом производства продукции. Системы ERP управляют бизнес-процессами, связанными с этапами разработки, подготовки производства и производства продукции. И только системы CALS управляют бизнеспроцессами, связанными со всеми этапами жизненного цикла изделия.
Было бы неправильным считать CALS панацеей при решении всех проблем
предприятия. В тоже время CALS является одним из важнейших компонентов
при решении проблемы повышения конкурентоспособности промышленного изделия, который необходимо использовать вместе с другими способами повышения
эффективности процессов ЖЦ.
В этом случае электронный бизнес (e-business) – интегрированная информационная система, состоящая из CRM-, SCM- и ERP-систем управления и позволяющая предприятию организовать эффективное взаимодействие со своими
контрагентами и оптимизировать бизнес-процессы по нужным критериям, в частности для получения максимальной прибыли.
Для оценки экономической эффективности внедрения информационных систем применяют несколько показателей. Среди них наиболее известными являются:
• показатель совокупной стоимости владения – TCO (Total Cost of Ownership);
• показатель возврата инвестиций – ROI (Return On Investment);
• показатель анализа выгодности затрат (показатель оценки издержек и экономических выгод) – CBA (Cost Benefits Analysis).
Для примера рассмотрим, как можно оценить эффект от инвестиций в CALS
с помощью показателя ROI, характеризующегося отношением стоимости инвестиций и выгоды, которую они приносят:
ROI = (a–b)/b,
где a – выгода от внедрения; b – стоимость инвестиций.
Сам показатель ROI во многом зависит от специфики предприятия. Однако
есть общие, не зависящие от специфики конкретного предприятия выгоды, которые приносит внедрение CALS. Так, основными выгодами от CALS можно назвать:
• общее повышение производительности труда. Достигается за счет повышения индивидуальной производительности сотрудников, глобализации и распределения бизнеса, а также повышения коллективной производительности. При этом
индивидуальная производительность сотрудников повышается за счет оптимизации расхода рабочего времени: сотрудники больше времени тратят на выполнение
своих прямых обязанностей и меньше – на выполнение обеспечивающих функций.
Появляется возможность эффективно сотрудничать с географически удаленными
партнерами и распределять свои производственные мощности. Повышается производительность коллективной работы, значительно сокращается количество ошибочных решений, принимаемых контрагентами из-за наличия у них устарелой исходной информации;
69
• общее снижение материальных затрат. Достигается за счет детального учета
требований к изделию на ранних этапах и отслеживания их выполнимости в последующем, что позволяет выявить большинство ошибочных решений в виртуальном прототипе изделия, а не в физическом его воплощении. При этом значительно
повышается количество заимствованных и типовых решений;
• общее повышение прибыли. Достигается за счет расширения доли рынка,
более раннего выпуска изделий по сравнению с конкурентами и представления
большего количества модификаций продукции, учитывающей больше потребностей клиентов.
В результате, если все вышеперечисленные выгоды преобразовать в количественные параметры, можно получить следующую формулу для расчета ROI:
ROI = (c–d)/d,
где c – выгода (от повышения производительности + от снижения затрат + от повышения прибыли); d – стоимость инвестиций.
Перечисленные выгоды от внедрения CALS не дублируют выгоды, получаемые от ERP,CRM и SCM, среди которых в основном выделяют:
• снижение транспортно-заготовительных расходов;
• снижение задержек отгрузки готовой продукции;
• уменьшение страховых запасов (уровень неснижаемых остатков на складах);
• снижение производственного брака;
• уменьшение затрат на административно-управленческий аппарат;
• сокращение производственного цикла;
• уменьшение складских помещений;
• увеличение оборачиваемости товарно-материальных запасов.
2.7. КОНТРОЛЬНЫЕ ВОПРОСЫ
1. Дать определение продукта и его деление на категории.
2. Что такое жизненный цикл изделия?
3. Дать определение конкурентоспособности.
4. Иерархические уровни управления в промышленности.
5. Цель концепции CALS.
6. Основные компоненты концептуальной модели CALS.
7. Дать определение модели Н. Окино.
8. Охарактеризовать структуру ИИС во взаимодействии с процессами ЖЦ
продукции.
9. Основные компоненты ОБДИ.
10. Что такое виртуальное предприятие?
11. Дать определение единого информационного пространства.
70
3. СТАНДАРТЫ CALS
Основной стратегией разработки и внедрения CALS является создание единой
индустриальной информационной инфраструктуры. При этом приоритет отдастся
разработке и последующему применению международных стандартов, подготовка
и принятие которых проводится через Международный комитет по стандартизации
(ISO). Тем не менее каждая страна формирует свою программу разработки CALS
с учетом ее национальных интересов.
Например, основой программы CALS Министерства обороны США является
использование и адаптация нескольких национальных и международных стандартов по электронному обмену данными в ряд стандартов спецификации «MIL»,
с целью обеспечения возможности совместного использования информации, создаваемой в различных компьютерных системах.
В качестве примера можно привести MIL-HDBK-59, «Руководство по программе применения компьютерного обеспечения и технологического обслуживания (CALS) Министерства обороны», которое обеспечивает инструкциями и указаниями по применению CALS в программах приобретения оборонных систем.
Даны примеры типов цифровых данных для подготовки, а также приложения различных стандартов к возможным ситуациям.
MIL-HDBK-59 охватывает больше, чем только стандарты по передаче данных. Обсуждена общая философия CALS МО, а также место CALS по отношению
к другим инициативам МО, таким как Общее руководство качеством (TQM), Совместное техническое обеспечение и RAM-CAD. CALS представлена в MIL-HDBK
как средство для улучшения общего цикла оборонного приборостроения, включая
электронную передачу данных. Акцент сделан на реальном внутреннем использовании данных в цифровой форме оборонными поставщиками в качестве средства
улучшения их работы.
Стандарты CALS покрывают спектр потребностей пользователей, обеспечивая единое проставление текста, графики, информационных структур и данных
о проекте, сопровождении и производстве, включая звук, видео, мультимедийные
средства, передачу данных, хранение данных, документацию и многое другое
для всех приложений.
Имеется множество стандартов, которые вписываются в концепцию CALS,
большинство из них либо уже являются международными стандартами ISO, либо
в ближайшем будущем станут таковыми. Таким образом, CALS-ориентированныс
стандарты изначально направлены на обеспечение возможности связи между различными отраслями промышленности как внутри отдельного государства, так
и во всем мире.
Данные стандарты и их использование позволит определить совместно используемые информационные ресурсы, доступные всем заинтересованным пользователям (прикладными положениями).
Существующие стандарты CALS условно делятся на функциональные (описывающие идеологию решения задач) и технические (определяющие модели
и структуры данных для обмена или совместного использования). Кроме того,
71
они классифицируются по этапам жизненного цикла и объекту описания. Например, выделяются данные о продукте, процессах и среде. Всего существуют пять
групп стандартов ЕИП:
1. Функциональные стандарты предназначены для описания бизнеспроцессов предприятия и их влияния на данные об изделии. Они определяют процедуру функционирования ЕИП. Примерами являются: известная методология
функционального моделирования IDEFO (FIPS 183), задающая способ описания
процессов; спецификации коалиции производителей workflow-систем (Workflow
Management Coalition – WfMC) – способ представления и обмен данными о рабочих потоках (workflow); стандарты календарного планирования.
2. Информационные стандарты предназначены для классификации структуры данных об изделии, используемой всеми участниками ЖЦ при выполнении
бизнес-процессов. Базовым является международный стандарт для обмена данными об изделии ISO 10303 (STEP). Кроме него сюда входят родственные ему стандарты описания каталога деталей (ISO 13584 PLIB), производственной среды
(ISO 15531 Manufacturing management data, MANDATE), ISO 14959 Parametrics.
3. Стандарты на программную архитектуру рассматривают архитектуру
программных средств, позволяющую им обмениваться данными без непосредственного участия человека. Таким образом, становится реальным взаимодействие
различных программ, изначально не ориентированных друг на друга, но построенных на основе одинаковой программной архитектуры. В качестве примера можно
назвать CORBA (Common Object Request Broker Architecture) и DCOM (Distributed
Component Object Model).
4. Коммуникационные стандарты предназначены для описания способов
физической передачи данных между компьютерными системами. Основой коммуникационных CALS-стандартов являются стандарты сети Internet.
5. Стандарты на интерфейс с пользователем описывают интерфейс, который программные системы предоставляют для диалога с пользователем, а также
процедуры их взаимодействия.
В общий состав нормативной базы CALS входят стандарты ISO, НATO и отдельных государств (например, ГОСТы РФ, федеральные стандарты США или
стандарты Великобритании). Рассмотрим основные стандарты и некоторые характерные задачи, решаемые на их основе.
3.1. STEP-СТАНДАРТ ДЛЯ ОПИСАНИЯ ДАННЫХ ОБ ИЗДЕЛИИ
Информация, создаваемая об изделии на отдельных стадиях его ЖЦ, широко
используется на протяжении всего ЖЦ. Использование информации производится
с помощью различных компьютерных систем, в том числе расположенных в различных организациях. Для организации ЕИП для всех участников ЖЦ изделия,
обеспечивающего подобное использование информации об изделии, в CALS-технологиях предлагается применение интегрированной информационной модели изделия, содержащей в себе о нем полную информацию.
72
Таким образом, возникает потребность в единой, понятной для компьютеров
форме представления информации об изделии, которая к тому же должна обеспечивать организацию информационного обмена между различными компьютерными системами. Для обеспечения возможности рационального управления информацией об изделии последняя должна быть определена в соответствии с международными стандартами.
Согласно стратегии CALS вся информация об изделии должна быть стандартизована. Поэтому начиная с 1984 г. многие страны, организации, компании вели
и продолжают вести в рамках ISO работы по созданию международного стандарта
по описанию, передаче и хранению данных об изделии, а также программных инструментов, обеспечивающих поддержку такого стандарта.
Центральное место в системе CALS-стандартов занимают стандарты, разработанные под эгидой Международной организации стандартизации ISO и получившие название STEP (Standard for the Exchange of Product Model Data) и номер
10303 (рис. 3.1). Цель стандарта – предоставить нейтральный механизм описания
(моделирования) данных о продукте на всех стадиях его жизненного цикла. ISO 10303 –
международный стандарт для компьютерного представления и обмена данными
о продукте – один из первых в семействе специализированных CALS-стандартов.
Он является характерным примером информационного стандарта нового поколения, по образу и подобию которого строятся последующие CALS-стандарты.
Рис. 3.1. Базовые стандарты CALS
В STEP используются следующие важные понятия:
• AAM – Application Activity Model – это функциональная модель IDEF0
для определенного приложения;
• ARM – Application Requirements Model – это модель, представляющая данные с точки зрения пользователя. В частности, в этой модели данные могут быть
выражены как средствами, типичными для приложения, так и с использованием
синтаксиса языка Express;
73
• AIM – Application Interpreted Model – это ARM модель, переведенная
в STEP-представление с использованием ряда унифицированных в STEP понятий,
закрепленных в интегрированных ресурсах;
• AP – Application Protocol – это STEP-стандарт, отражающий специфику конкретного приложения;
Единообразная форма описаний данных о промышленной продукции обеспечивается введением в STEP языка Express, инвариантного к приложениям. В стандартах STEP использован ряд идей, ранее воплощенных в методиках информационного IDEF1X и функционального IDEF0 проектирования. Но роль стандартов
STEP не ограничивается введением только грамматики единого языка обмена данными. В рамках STEP предпринята попытка создания единых информационных
моделей (онтологий) целого ряда приложений. Эти модели получили название
прикладных протоколов.
STEP – это совокупность стандартов и состоит из ряда томов. Тома имеют
свои номера № и обозначаются как «часть №» или ISO 10303-№. К настоящему
времени разработано более сотни томов, часть из них имеет статус проектов, часть
уже утверждена в качестве стандартов 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).
В стандарте ISO 10303 описываются основные принципы STEP, правила языка Express, даны методы его реализации, модели, ресурсы, как общие для приложений, так и некоторые специальные (например, геометрические и топологические
модели, описание материалов, процедуры черчения, конечно-элементного анализа
и т.п.), прикладные протоколы, отражающие специфику моделей в конкретных
предметных областях, методы тестирования моделей и объектов.
Удовлетворению требований создания открытых систем в STEP уделяется основное внимание – специальный раздел посвящен правилам написания файлов обмена данными между разными системами, созданными в рамках STEP-технологии.
74
STEP обеспечивает единое представление информационной модели изделия
в форме группы интегрированных ресурсов (описаний и структур), которые вместе
обеспечивают полное и однозначное определение изделия. Кроме того, интегрированные ресурсы описаны на едином языке описания изделия. Представление информации о модели изделия может быть выполнено несколькими различными способами при условии, что интегрированные ресурсы независимы от формы реализации.
В настоящий момент некоторые программные инструментальные средства,
поддерживающие стандарт STEP, уже доступны на рынке (фирмы ITI, StepTools),
многие находятся в стадии разработки или готовятся к выпуску.
В России готовится к выпуску первая версия программного продукта – «Интегрированная среда разработки CALS-систем» «IntegroCALS».
3.1.1. МЕТОДЫ ОПИСАНИЯ
Первая группа документов – тома с номерами в диапазоне с 11 до 19, тома
предназначены для описания диалектов языка Express.
№ = 11: Express (Express language reference manual) – основное руководство
по языку Express. Содержит также описания расширения Express-C базового языка
и графического варианта языка Exspress-G. Базовый язык приспособлен для описания и передачи статических свойств объектов приложений, т. е. параметров
структур и ограничений. Расширение языка Express-C включает средства описания
динамических свойств объектов (добавлено описание событий и транзакций).
Для наглядности представления языковых конструкций в Express предусмотрены
графические средства изображения моделей, в качестве которых может использоваться специальное дополнение Express-G (графичесский Express). Express-G –
язык диаграмм, отдаленно напоминающий язык описания информационных моделей в методике IDEF1X.
№ = 12: Express-I (Language Reference Manual). Express-I – расширение языка,
предназначенное для описания отдельных экземпляров данных.
№ = 14: Express-X (Mapping and view language) – промежуточный язык, аналогичный Express-M и используемый для описания соответствий между типами
данных в заданной исходной Express-схеме и создаваемыми новыми ее вариантами
(views); в качестве views могут использоваться форматы с описанием того же множества сущностей, что и в Express-схеме, например формат IGES.
Разрабатываются также дополнения, относящиеся к следующим диалектам
языка:
Express-M: Mapping definition language; язык Express-X служит для описания
соответствий между сущностями и атрибутами некоторых моделей, представленных в виде схем на языке Express. Например, этими схемами могут быть два разных прикладных протокола, имеющих частично общие данные, или две схемы одного приложения, но созданные разными лицами (при отсутствии соответствующего AP).
75
В Express-X и Express-M одна схема есть схема-источник, другая – целевая
схема. Целевых схем может быть несколько при одной схеме-источнике. Предложения Express-X (Express-M) транслируются на язык C, результирующая программа представляет собой совокупность обращений к функциям базы данных SDAI
в STEP-среде. Другими словами, транслятор относится к системе SDAI (см. протокол ISO10303-22), а Express-X можно рассматривать как язык 4GL для обращений
к функциям базы данных SDAI.
Express-P (Process definition language) – язык диаграмм для представления
процессов, методов и коммуникационных структур.
Express-V – язык, предназначенный для получения ARM-представлений
из AIM-моделей, другими словами, для описания процедур поиска экземпляров
Express-объектов, отвечающих заданным условиям, и доступа к ним, например,
при создании новых ARM. Эти создаваемые ARM-представления обычно не требуют столь всестороннего описания приложения, как в AIM, и потому могут быть
существенно проще.
В Express-V имеются:
1) схема-источник (AIM), обычно это прикладной протокол, например AP203;
2) схема-цель, задающая сущности, которые должны быть в создаваемой частной модели;
3) схема отображения нужных сущностей из источника в цель. На языке
Express-V описываются условия (в виде клозов WHEN) такого отображения. Берется подходящая уже существующая AIM как источник, все совпадающие объекты переводятся в ARM, далее описываются оригинальные объекты. Дополнительной возможностью реализаций Express-V является обратное отображение специфики создаваемой ARM в исходную AIM с целью развития прикладных
протоколов.
Для возможности применения языка Express должны быть разработаны методы реализации (Implementation Methods), которые могут быть представлены средствами файлового взаимодействия, построением БД, интерфейсом с языками программирования.
3.1.2. МЕТОДЫ РЕАЛИЗАЦИИ
Вторая группа (тома с номерами 21–29) имеет название «Методы реализации», она служит для реализации межпрограммного информационного обмена между прикладными системами в STEP-среде. Предусмотрены межпрограммные связи с помощью обменного файла и доступа к БД.
№ = 21: Clear Text Encoding of the Exchange Structure (physical transfer file format); стандарт устанавливает правила оформления обменного файла. Обменный
файл играет в STEP важную роль; если собственно на языке Express определены
сущности, то именно в обменном файле задаются экземпляры этих сущностей.
Прикладные программы для связи со STEP-средой должны читать и генерировать
обменные файлы.
76
№ = 22: Standard Data Access Interface Specification; содержит описание
SDAI – системы представления данных и доступа к данным конкретных прикладных систем (чаще всего это CAD/CAM-системы). Данные, участвующие в межпрограммных связях, образуют SDAI-модели. В системе SDAI предусматривается
компилятор кода, конвертирующего эти модели в SDAI-базу данных, а также
функции обращения к этой базе данных. Возможно непосредственное построение
прикладных систем, работающих с SDAI-базой данных.
Тома с номерами № = 23–29 устанавливают правила обращения к данным
в SDAI-базе данных на языках программирования C++, C, Java, на языке моделирования UML, на языке передачи данных в системах распределенных вычислений
IDL, языке разметки XML.
Остальные тома стандарта ISO 10303 посвящены описанию тестирования моделей, представленных на языке Express, интегрированным ресурсам, прикладным
протоколам и прикладным компонентам.
3.2. ТЕХНОЛОГИИ ПРЕДСТАВЛЕНИЯ ДАННЫХ И ИНФОРМАЦИОННЫЕ МОДЕЛИ
ПО ИСО 10303 (STEP)
Как указано выше, для структурированного представления данных в ИИС
разработан ряд международных стандартов и спецификаций. В них описаны и регламентированы технологии представления данных и информационные модели
для различных предметных областей.
Совокупность стандартов ИСО серии 10303 (STEP) описывает комплексную
технологию управления данными об изделии. Эти данные представляются в виде
репозитория (хранилища), роль которого может выполнять база данных или электронный документ.
Стандарт содержит описание комплекса типовых информационных моделей,
касающихся различных аспектов изделия: его состава и структуры, геометрической формы, материалов, требований к точности и т. д. Эти типовые модели называются интегрированными ресурсами (integrated resources).
Помимо интегрированных ресурсов стандарт содержит типовые информационные модели объектов (изделий) для ряда предметных областей (судостроения,
автомобилестроения и т. д.). Эти модели построены в основном на базе интегрированных ресурсов и называются протоколами применения (application protocol).
Стандарт ИСО 10303 не только содержит готовые протоколы для различных предметных областей, но и описывает методику создания, тестирования и аттестации
новых протоколов.
Для описания информационных моделей (интегрированных ресурсов и протоколов применения) используется специально разработанный язык описания данных – Express.
Стандарт не касается вопросов реализации БД, но предусматривает форму
представления данных в виде электронного документа – текстового обменного
файла, имеющего строго регламентированную структуру. Обменный файл используется для передачи данных между различными компьютерными системами
77
или представления и хранения результатов работы автоматизированных систем
проектирования.
Стандарт также содержит спецификацию стандартизованного интерфейса
доступа к данным (Standard Data Access Interface – SDAI). Эта спецификация представляет собой набор функций для языков программирования С и C++, обеспечивающих доступ к объектам в репозитории.
Для аттестации и сертификации прикладных программных средств, работающих с данными в формате ИСО 10303, в стандарте предусмотрен комплекс тестов
и методик аттестационного тестирования.
Общая структура и взаимосвязь составных частей стандарта ИСО 10303 приведены на рис. 3.2.
Рис. 3.2. Взаимосвязь основных разделов стандарта ИСО 10303 STEP
Раздел «Методы описания» содержит две нотации объектно-ориентированного языка Express – текстовую и графическую.
Раздел «Методы реализации» описывает требования к структуре текстового
обменного файла и программный интерфейс доступа к данным (SDAI).
В разделах «Общие интегрированные ресурсы», «Прикладные интегрированные ресурсы» и «Прикладные решения» описываются типовые элементы информационных моделей, из которых конструируются протоколы применения, соответствующие конкретным предметным областям. Согласно требованиям стандарта
ИСО 10303 протокол применения должен, как минимум, на 85 % состоять из объектов, наследуемых от объектов – интегрированных ресурсов.
Раздел «Протоколы применения» содержит готовые модели данных для различных прикладных областей (машиностроение, судостроение, автомобилестроение, электроника, строительство и др.) путем использования прикладных про78
граммных интерфейсов (API – Application Programming Interface). Например, протокол ИСО 10303 АР203 «Configuration controlled design» определяет структуру
данных информационной модели машиностроительного изделия, имеющего
различные варианты конфигурации.
Разделы «Методология аттестационного тестирования» и «Набор базовых
тестов» содержат общие требования по организации аттестации программного
обеспечения и наборы тестов для каждого протокола применения.
Тестирование выполняется в два этапа:
а) тестируемая система читает тестовый обменный файл, а затем перечень обнаруженных в нем объектов сравнивается с содержанием теста;
б) в тестируемой системе создается описание заданного в тесте набора объектов и на их основе генерируется обменный файл, который сравнивается с исходным.
Развитием STEP-технологии, введенной в ИСО 10303, является семейство
стандартов, регламентирующих информационное описание комплектующих изделий (ИСО 13584 Parts Library), производственных ресурсов различного вида (ИСО
15531 Manufacturing Management Data), изделий для нефте-, газового комплекса
(ИСО 15926 Oil and Gas). Все эти стандарты содержат описанные выше компоненты STEP-технологии.
Кроме перечисленных стандартов существует ряд опубликованных спецификаций. К их числу относятся STEP PDM Schema и NATO Product Data Model.
С 1999 г. выполняется проект PLCS (Product Life cycle Support), в рамках которого разрабатывается протокол применения STEP (АР239), направленный
на обеспечение информационной поддержки всего ЖЦ изделия. Участниками
и спонсорами проекта являются ведущие западные компании и государственные
учреждения (Airbus Industry, The Boeing Company, The Baan Company, BAE SYSTEMS, The Finnish Defense Forces (FDF), Lockheed Martin Government Electronic
Systems, LSC Group Ltd., Norwegian Defense & DNV, PTC, Rolls-Royce (PLC), Saab
Aerospace, U.K. Ministry of Defense (MoD), United States Department of Defense
(DoD)).
Детальный анализ и изучение разработанных и разрабатываемых спецификаций
и стандартов необходимы для того, чтобы подойти к созданию интегрированной информационной модели всего комплекса взаимосвязанных объектов, описывающих ЖЦ изделия.
Спецификация STEP PDM Schema
(SPS) разработана фирмами ProSTEP и PDES
на базе протоколов АР203, АР212, АР214
и АР232 (рис. 3.3) и определяет концептуальную модель базы данных проекта машиностроительного изделия управляемой конфигурации с точки зрения разработчика. Ее слеРис. 3.3. Позиционирование и содердует рассматривать как результат развития
жание модели PDM Schema (SPS)
и гармонизации перечисленных протоколов
STEP.
79
В спецификации SPS рассматриваются следующие аспекты информационного
описания изделия:
• классификация изделия;
• свойства изделия, в том числе геометрическая форма;
• структура изделия и взаимосвязь его составных частей;
• управление конфигурацией и применяемость составных частей;
• идентификация изделий-аналогов;
• авторизация данных;
• управление процессом проектирования;
• документы и внешние файлы данных.
Спецификация NATO Product Data Model (NPDM) представляет собой
концептуальную модель инженерных данных, предназначенную для информационного сопровождения ЖЦ продукции военного назначения. Как и SPS, NPDM
построена на основе идеологии и интегрированных ресурсов стандарта STEP.
С другой стороны, модель ориентирована на задачи, решаемые НАТО. Поэтому
она содержит ряд новых понятий и соответствующих им интегрированных ресурсов, связанных прежде всего с задачами ИЛП.
Различные версии NPDM были использованы в проектах создания CALS-систем
в Японии, Финляндии, Турции, Италии, Франции и других странах. С учетом полученного опыта модель последовательно совершенствовалась (в настоящее время
действует NPDM версии 4.10).
В отличие от протоколов ISO 10303 АР203, АР214 и им подобных в NPDM
изделие рассматривается, как минимум, с трех точек зрения (view): заказчика
(AS REQUIRED), разработчика (AS DESIGNED) и эксплуатанта (AS-BUILT /
AS-USED), соответствующих разным стадиям ЖЦ. Этим точкам зрения соответствуют следующие базовые понятия:
• концепция изделия (product concept) – совокупность данных, задаваемых
и используемых заказчиком;
• конструкторская (проектная) модель изделия (product definition) – совокупность данных, используемая в ходе разработки изделия, а также отображающая
результаты проектирования;
• эксплуатационная модель изделия (экземпляра изделия или партии изделий – product instance) – совокупность данных, необходимых для эксплуатации
и обслуживания.
Концепция изделия формируется заказчиком на самых ранних стадиях ЖЦ
и содержит предполагаемые условия использования (usage scenario) и требуемые
тактико-технические характеристики (specification). В соответствии с заданной
концепцией разрабатывается проектная документация. На ее основе изготавливаются экземпляры или партии изделий. Для планирования деятельности по обслуживанию экземпляра изделия и оптимизации эксплуатации требуется мониторинг
его состояния и использования. В ходе проектирования изделия и анализа логистической поддержки рассматриваются возможные проблемы (anomaly), которые
могут иметь место при эксплуатации. Уже на этой стадии определяется состав работ (операций) и ресурсов, необходимых для предотвращения (минимизации) этих
нежелательных событий или ликвидации их последствий.
80
Рис. 3.4. Структура модели NPDM:
1 – концепция изделия и его характеристики; 2 – управление конфигурацией изделия; 3 – организационная структура, используемая в ходе проектирования, производства, эксплуатации и обслуживания; 4 – изменения конфигурации и связанные с ними задачи логистического обеспечения;
5 – даты и время процессов и событий; 6 – использование изделия и его обслуживание; 7 – сведения
о контрактах, в соответствии с которыми выполняются работы; 8 – требования к обеспечению
информационной безопасности; 9 – утверждения результатов и роли лиц, осуществляющих утверждения; 10 – техническая документация; 11– задачи, связанные с обслуживанием изделия и устранением неисправностей; 12 – данные о возможных неисправностях; 13 – проектно-конструкторские
данные об изделии, в том числе многовариантное представление структуры изделия и его характеристик; 14 – экземпляр изделия
Модель NPDM включает набор схем (рис. 3.4), соответствующих перечисленным аспектам информационного описания изделия.
На основе схем NPDM создается комплекс взаимосвязанных баз данных, используемых при решении различных задач в ходе ЖЦ изделия.
Ниже приведен анализ моделей данных, представленных в SPS, NPDM, ИСО
10303 АР203, ИСО 15531, затрагивающих с разной степенью подробности различные аспекты ЖЦ изделия.
3.3. ПРОЕКТНЫЕ ДАННЫЕ ОБ ИЗДЕЛИИ
Понятие изделия в ИСО 10303 и NPDM соответствует классу физических
объектов, таких как конечное изделие, сборочная единица, материал и т. д. Обозначение и наименование изделия указываются посредством информационного
81
объекта PRODUCT (PRD). Изделие может иметь одну или несколько модификаций, указываемых посредством объекта PRODUCT DEFINITION FORMATION
(PDF). Соответственно, с одним объектом PRD могут быть связаны один или несколько объектов PDF.
В примере, приведенном на рис. 3.5, представлены три изделия (PRD), входящие в состав двигателя внутреннего сгорания (ДВС): блок цилиндров, коленчатый
вал и поршневая группа. Каждое изделие имеет три модификации (PDF) для ДВС
с разным объемом цилиндров (1,4 л, 1,8 л и 2 л). Как будет показано далее, между
объектами PDF могут быть заданы связи, отражающие иерархию компонентов
в сборке. Таким образом, набор объектов PDF (модификаций составных частей)
соответствует составу конкретной модификации конечного изделия.
Для решения конструкторских, технологических, эксплуатационных и других
задач необходимо одновременно поддерживать несколько вариантов состава
и структуры изделия с учетом контекста. Например, состав изделия в технологическом контексте (в отличие от конструкторского) может содержать промежуточные
технологические подсборки. В эксплуатационном контексте состав изделия включает в себя только те компоненты, с которыми выполняются регламентные работы
и т. д.
Рис. 3.5. Представление изделий и их модификаций объектами PRD и PDF
82
Для моделирования состава изделия в разных контекстах в ИСО 10303 введены специальные объекты: определение изделия – PRODUCT DEFINITION (PD) –
и контекст определения изделия – PRODUCT DEFINITION CONTEXT (PDC). Таким образом, с одним объектом PDF может быть связано несколько объектов PD,
соответствующих различным контекстам (PDC). Цепочка объектов PDC = > PD =>
PDF позволяет задать состав изделия в конкретном контексте.
Схема данных в нотации Express-G, описывающая взаимосвязь рассмотренных объектов, представлена на рис. 3.6.
PRODUCT
Изделие
Id
Name
Description
Frame of reference
PRODUCT_ DEFINIT10N_F0RMAT10N
Обозначение изделия
Наименование изделия
Описание изделия
Контекст
Модификация изделия
Id
Description
of_product
Обозначение
Описание
Ссылка на объект «Изделие»
PRODUCT_DEFINITION
Id
Description
Formation
Frame of reference
PRODUCT_ DEFINITION_CONTEXT
Определение изделия
Обозначение
Описание
Ссылка на объект «Модификация изделия»
Ссылка на объект «Контекст»
Контекст
Рис. 3.6. Схема взаимосвязи основных объектов, идентифицирующих изделие
83
Отношения между изделиями описываются при помощи объекта PRODUCT
DEFINITION RELATIONSHIP (PDR). Эти связи могут быть двух типов: «входит
в…» (состоит из) и «изготавливается из...» (отношение преобразования).
Для описания связей типа «входит в...» (описания структуры) используются
подтипы объекта PDR: NEXT_ASSEMBLY USAGE OCCURENCE (NAUO),
ASSEMBLY COMPONENT USAGE (ACU) и PRODUCT DEFINITION USAGE
(PDU). Каждый экземпляр объекта NAUO соответствует одному изделию, входящему в сборку. Если же в сборку входит несколько одинаковых изделий, их число
можно указать при помощи одного экземпляра комплексного объекта, состоящего
из NAUO и объекта QUANTIFIED ASSEMBLY COMPONENT USAGE (QACU).
Пример описания структуры изделия с использованием перечисленных объектов приведен на рис. 3.7.
Рис. 3.7. Пример описания структуры изделия (отношений «состоит из…»)
Отношение между изделиями «изготавливается из...» можно описать несколькими способами. На стадии проектирования конструктор указывает только материал, из которого должна быть изготовлена деталь, но не указывает его потребное
количество. Для такого описания используется объект DESIGN MAKE FROM
RELATIONSHIP (DMFR). На стадии технологической подготовки производства
84
технолог может указать один или несколько вариантов изготовления детали
с использованием различных заготовок. Для такого описания используется объект
MAKE FROM USAGE OPTION (MFUO).
Взаимосвязь объектов, описывающих отношения между изделиями, представлена на рис. 3.8.
PRODUCT DEF/NITION RELATIONSHIP
Отношения между изделиями
Id
Обозначение
Name
Наименование
Description
Описание
Relating_product_definition
Ссылка на базовое изделие
Related_product_definition
Ссылка на входящее изделие
NEXT ASSEMBLY USAGE OCCURRENCE
(NAUO)
Ссылка на соседний элемент иерархии
Id
Позиция
Рис. 3.8. Взаимосвязь объектов, описывающих отношения между изделиями (см. также с. 86)
85
Name
Наименование
Description
Описание
relatingproductdefinition
Ссылка на определение вышестоящего
изделия (сборочной единицы)
Related_product_definition
Ссылка на определение входящего изделия
DESIGN MAKE FROM RELATIONSHIP (DMFR)
Ссылка на материал или полуфабрикат,
из которого изготавливается изделие
Id
Обозначение
Name
Наименование
description
Описание
relating product definition
Ссылка на определение изготовляемого
изделия (детали)
Related product definition
Ссылка на определение материала или
полуфабриката
MAKE_FROM_USAGE_OPTION (MFUO)
Ссылка на описание альтернативных
вариантов
Id
Обозначение
Name
Наименование
Description
Описание
relating product definition
Ссылка на определение изготовляемого
изделия (детали)
Related product definition
Ссылка на определение материала или
полуфабриката
Ranking
Приоритет данного варианта изготовления
ranking rationale
Обоснование приоритета
Quantity
Количество материала, требуемое
для изготовления одной детали
Рис. 3.8. Окончание
Каждое изделие (PRODUCT) может быть классифицировано, причем одновременно в нескольких системах классификации. Например: деталь может быть
телом вращения, элементом крепежа, изделием, разрешенным к использованию,
и т.д. Для описания классификации изделий используется объект PRODUCT
CATEGORY (отношение классификации) (рис. 3.9.). Одна категория может включать в себя другие и одновременно входить в состав других категорий.
86
PRODUCT CATEGORY
Категория, включающая в себя другие категории
Id
Обозначение
name
Наименование
description
Описание
PRODUCT RELATED PRODUCT
CATEGORY
Категория, входящая в другие категории
products
Изделия, отнесенные к данной категории
PRODUCT CATEGORY RELATIONSHIP
Отношения между категориями изделий
Name
Наименование отношения
Description
Описание отношения
Рис. 3.9. Взаимосвязь объектов, описывающих классификацию изделий
Для описания документов в стандарте ИСО 10303 предусмотрен объект
DOCUMENT (рис. 3.10). Каждый документ может иметь несколько версий, одна
из которых является текущей (активной). Когда происходит обращение к документу, рассматривается его текущая версия. Версия документа указывается через объект DOCUMENT REVISION. Для классификации документов используется понятие типа документа. Список возможных типов документов указывается с помощью
объекта DOCUMENT TYPE.
Объект DOCUMENT может быть связан с объектами CATEGORY, PRD, PDF,
PD и другими.
87
DOCUMENT
Документ
Id
Обозначение документа
Name
Наименование документа
Description
Описание документа
Kind
Ссылка на тип документа
Active
Ссылка на текущую версию
DOCUMENT TYPE
Тип документа
product data type
Наименование типа документа
DOCUMENT REVISION
Версия документа
Id
Обозначение версии документа
of document
Ссылка на базовый документ
Рис. 3.10. Взаимосвязь объектов, описывающих документы
В отличие от ИСО 1ОЗОЗ в модели NPDM для представления неструктурируемых наборов данных (документов) предлагается использовать объект INFO
OBJECT аналогичного назначения.
Любой набор информации об изделии может быть охарактеризован состоянием (статусом), являющимся результатом выполнения некоторого авторизованного
действия. Примерами таких действий являются: разработка, проверка, согласование, утверждение и т. д.
Присвоение статуса аналогично подписанию бумажного документа, поэтому
должны быть указаны роль и полномочия подписывающего лица.
Статус описывается объектом APPROVAL (рис. 3.11), который, в свою очередь, ссылается на объект APPROVAL STATUS. Каждый экземпляр объекта
APPROVAL STATUS описывает один из возможных статусов. Общее число возможных статусов зависит от прикладной области. Лицо, присваивающее статус,
указывается объектом APPROVAL PERSON ORGANIZATION. Данные, которым
присваивается статус, указываются с помощью объекта APPROVAL ASSIGNMENT.
88
APPROVAL
Присвоенный статус
Status
Ссылка на статус
Level
Уровень
date time of approval
Дата присвоения статуса
APPROVAL PERSON ORGANIZATION
Лицо, присваивающее статус в соответствии
с заданной ролью
person organization
Сотрудник, присваивающий статус
Role
Роль сотрудника, присваивающего статус
signature
Электронно-цифровая подпись
APPROVAL_ROLE
Роль, выполняя которую лицо утверждает данные
(присваивает им статус)
Role
Роль
APPROVAL_STATUS
Статус, присваиваемый объектам
Name
Наименование статуса
APPROVAL ASSIGNMENT
Связь статуса с данными
assigned approval
Статус, который присваивается данным
Items
Данные, которым присваивается статус
Рис. 3.11. Взаимосвязь объектов, описывающих статус
89
3.4. СТРУКТУРА МОДЕЛЕЙ НА ЯЗЫКЕ EXPRESS
Базовый для STEP-технологий язык Express описан в стандарте ISO 10303,
том 11. Язык является объектно-ориентированным, имеет универсальный характер,
его можно использовать для описания статических структур и их свойств в различных предметных областях, несмотря на то, что язык разрабатывался, прежде
всего, в качестве средства представления моделей промышленных изделий на разных этапах их жизненного цикла.
Описание некоторого приложения на языке Express в рамках стандартов STEP
называют Express-моделью (мodel). В модели декларируется множество понятий
и объектов, входящих в приложение, свойства и взаимосвязи объектов.
Модель состоит из одной или нескольких частей, называемых Expressсхемами (schema) или просто схемами, и обменного файла. Схема – раздел описания, являющийся областью определения данных. В ней вводятся необходимые типы данных. При описании свойств типов данных могут применяться средства процедурного описания – процедуры, функции, правила, константы. Обменный файл
содержит конкретные экземпляры типов данных.
Описание схемы начинается с заголовка, состоящего из служебного слова
schema и идентификатора – имени схемы. Далее следует содержательная часть –
тело схемы. Описание заканчивается служебным словом end_schema:
SCHEMA <имя_схемы>;
<тело_схемы>;
END_SCHEMA;
В языке Express-G схема представляется прямоугольником с разделительной горизонтальной линией, над этой линией записывается имя схемы, как это показано на рис. 3.12.
Рис. 3.12. Изображение схемы в языке Express-G
Для установления интерфейса между двумя схемами вводятся спецификации
интерфейса. Применяют два типа спецификаций – use и reference. Например:
SCHEMA s1;
ENTITY par1;
name: STRING;
END_ENTITY;
END_SCHEMA;
SCHEMA s2; ( * в схеме s2 в качестве параметра х используется
name из
s1.par1 *)
USE FROM s1.par1 (name AS x);
END_SCHEMA;
90
Ссылки типа use отличаются тем, что декларации сущностей из другой схемы
используются в данной схеме как свои локальные, в то время как reference просто
позволяет обращаться к декларациям другой сущности. Ограниченность reference
выражается в том, что сущности из другой схемы можно использовать только
в качестве типов атрибутов в сущностях данной схемы.
В языке Express-G используются диаграммы двух уровней. На схемном уровне (schema level) изображаются схемы и их взаимосвязи в виде линий. На сущностном уровне (entity level) изображаются типы, сущности, атрибуты, а для ссылок
на объекты другой схемы применяются специальные символы.
Эти символы представляют овальными фигурами. В овале записывают имя
схемы-источника и имя используемого определения. В нашем примере это ссылка
на s1.par1. Овал помещается внутрь прямоугольника, в котором дополнительно
указывается имя атрибута (в примере это name).
Для указания межстраничной связи, что требуется, если Express-G модель
размещается более чем на одной странице, используется овальный символ, внутри
которого указываются через запятую номер страницы и номер ссылки.
3.4.1. ТИПЫ ДАННЫХ В ЯЗЫКЕ EXPRESS
В теле схемы декларируются типы данных (Data Type). Тип данных – это
множество значений некоторой величины или множество объектов (набор экземпляров). В языке Express используются следующие типы данных: сущность (Entity),
простой (Simple Type), агрегативный (Aggregation Data Type), определяемый
(Defined Data Type), нечисловой (Enumeration Data Type) и выделяемый (Select
Data Type) типы.
Сущность – тип данных, представляющий набор концептуальных или реальных физических объектов с некоторыми общими свойствами. Сущности используют для описания объектов приложений. Свойства сущности выражают в виде
атрибутов (Attributes). К характеристикам сущностей относятся также ограничения, накладываемые на значения атрибутов или на отношения между атрибутами.
Описание сущности начинается со служебного слова ENTITY, за которым
следует идентификатор сущности, описания ее атрибутов и возможно также правил. Каждый из атрибутов представлен его идентификатором и типом:
ENTITY <имя_сущности>;
<идентификатор_атрибута>:<тип_атрибута>;
...
END_ENTITY;
Например, задание прямой линии (line) в виде двух инцидентных точек р0
и р1 (атрибутов типа point) выглядит следующим образом:
ENTITY line;
p0,p1: point;
END_ENTITY;
Атрибуты и переменные сами могут быть сущностями. Так, тип атрибутов p0
и p1 предыдущего примера декларируется как сущность, атрибутами которой
в случае пространства 3D являются геометрические координаты x,y,z:
91
ENTITY point;
x,y,z: REAL;
END_ENTITY;
В языке Express-G сущности изображаются прямоугольниками, внутри прямоугольника записывается имя
сущности (рис. 3.13).
Если свойство является необязательным для данной
Рис. 3.13. Изображение
сущности,
то его выражают так называемым необясущности в языке Express-G
зательным (optional) атрибутом. В его описании перед
типом атрибута добавляется служебное слово OPTIONAL:
<идентификатор_атрибута>: OPTIONAL <тип_атрибута>;
Изображение атрибутов в Express-G поясняет рис. 3.14, из которого, в частности, следует, что атрибут представлен прямоугольником, а связи «сущность–
атрибут» или «сущность–сущность» отображаются линиями, причем в случае связи с optional атрибутом используется пунктирная линия. Направление связи обозначается окружностью на конце линии, ведущей к атрибуту. Имя атрибута записывается рядом с этой линией. В прямоугольнике атрибута записывается тип
атрибута.
Рис. 3.14. Изображение атрибутов в языке Express-G
Некоторые из атрибутов могут определяться через другие атрибуты. Тогда атрибуты, выражаемые через другие атрибуты, называют порожденными (derived),
что отображается служебным словом derive в декларации атрибута. Например,
описание окружности, кроме обязательных атрибутов, которыми в нижеследующем примере выбраны радиус и центр окружности, может включать порожденный
атрибут «площадь круга»:
ENTITY point;
x,y,z: REAL;
END_ENTITY;
ENTITY circle;
center: point;
radius: REAL;
DERIVE
area: REAL := pi*radius**2;
END_ENTITY;
92
В этом примере использованы явные атрибуты center, radius и порожденный
атрибут area.
Отметим, что между символами (* и *) записывается комментарий – произвольный текст по усмотрению автора модели. Если комментарий умещается в одной строчке, то достаточно перед его текстом поставить двойной дефис ( – –).
К простым типам данных относятся следующие типы:
integer – целые числа;
real – вещественные числа;
number – тип, объединяющий типы integer и real;
logical – его значениями могут быть true, false или unknown (неопределенность);
Boolean – с возможными значениями true или false;
binary – последовательность битов 1 или 0;
string – строка символов.
Изображения простых типов на языке Express-G показаны на рис. 3.15.
Рис. 3.15. Изображения простых типов в языке Express-G
Для binary и STRING в круглых скобках можно указать максимально возможное число элементов множества, например, если строка A может включать до
24 символов, то:
A: STRING(24);
Если строка должна содержать ровно 24 символа, то:
A: STRING(24) FIXED;
Если же ограничений на длину строки нет, то:
A: STRING;
Если переменная х имеет тип binary, то выражение х[5:7] означает биты с 5-го
по 7-й в коде х.
Значения простых типов выражаются с помощью литералов. Литералы – это
числа (целые, вещественные), двоичные коды, логические значения (true, false,
unknown), фрагменты текста (строковый тип). Примеры записи литералов:
• двоичный (начинается со знака %) %100101110
• целое десятичное число 1052
• вещественный (обязательна десятичная точка) 34.е-3 или 0.034
• строковый (занимает не более одной строки) 'first name'
Агрегативный тип данных – множество элементов некоторого типа. Различают четыре разновидности агрегативных типов, сведения о которых приведены
в табл. 3.1.
93
Таблица 3.1
РАЗНОВИДНОСТИ АГРЕГАТИВНЫХ ТИПОВ
Тип
данных
Упорядоченность
Различие элементов
ARRAY
Да
Необязательно
BAG
Нет
Необязательно
LIST
Да
Обязательно
SET
Нет
Обязательно
При описании типа массив (array) после слова array в квадратных скобках указываются нижняя и верхняя границы индексов. Для остальных агрегативных типов
записываются не граничные значения индекса, а нижняя и верхняя границы числа
элементов. Например:
F1: ARRAY[2:8] of REAL;
(* массив F1 из 7 элементов, элементы имеют тип REAL и нумеруются
начиная с индекса 2 *);
F2: LIST[1:?] of INTEGER;
(* множество F2 содержит, по крайней мере, один элемент типа INTEGER *)
matr: ARRAY[1:10] of ARRAY[9:12] of atrac;
(* массив matr состоит из 10 четырехэлементных массивов, элементы типа atrac *)
Записи вида array[2:8] или list[1:?] в Express-G преобразуются в форму A[2:8]
или L[1:?], указываемую около линии атрибута агрегативного типа после имени
этого атрибута. Так, первый из вышеприведенных примеров представлен на рис.
3.16.
Рис. 3.16. Пример изображения агрегативного типа в языке Express-G
Определяемый тип данных обычно вводится пользователем для улучшения
читаемости модели. Нечисловой тип – тип данных, экземплярами которого являются нечисловые (предметные) переменные. Выделяемый тип соответствует поименованной совокупности других типов. Описание этих типов данных начинается
со служебного слова type, за которым следует идентификатор типа и его определение. Пример описания определяемого типа:
TYPE volume = real;
END_TYPE;
ENTITY manual;
94
name: STRING;
v1,v2,v3: volume;
END_ENTITY;
Определение нечислового типа начинается со служебных слов enumeration of,
после которых в скобках перечисляются элементы множества. Например:
TYPE color = ENUMERATION OF (red, green, blue);
END_TYPE;
Ссылка на значение red теперь возможна в виде red или color.red.
Выделяемый тип соответствует одному из некоторого списка уже введенных
типов. Этот список записывается после служебного слова select. Ссылка на имя
выделяемого типа означает, что выбирается один из типов совокупности:
TYPE a_c = SELECT (one, two, three);
END_TYPE;
...
proc: a_c; (* proc может быть объектом одного из типов one, two, three *)
Графические изображения определяемых, нечисловых и выделяемых типов данных показаны на рис. 3.17. Внутри прямоугольников, ограничиваемых пунктирными
линиями, записывается имя типа.
Способ описания констант очевиден
из следующего фрагмента модели:
CONSTANT
year: INTEGER := 1995;
start: date := date(12,16,1982);
(* подразумевается, что при описании
Рис. 3.17. Изображения определяемых,
нечисловых и выделяемых типов данных типа date указаны три атрибута
в языке Express-G
месяц, число, год *)
END_CONSTANT;
3.4.2. ЯЗЫК EXPRESS: СУПЕРТИПЫ И ПОДТИПЫ
Отношения агрегирования (типа целое–часть) или отношения обобщения
(функция–вариант реализации), характерные для представления структур объектов
в виде альтернативных (И-ИЛИ)-деревьев, в языке Express выражаются в форме
отношений между типами данных. Для этого введены понятия супертипа
(supertype) как более общего типа и подтипов (subtypes) как подчиненных типов.
На рис. 3.18 верхняя сущность относится к супертипу, а три нижних прямоугольника изображают подтипы, линии связи прямоугольников должны быть утолщенными.
95
Рис. 3.18. Изображение супертипов и подтипов
в языке Express-G
Рассмотрим пример фрагмента (И-ИЛИ)-дерева, в котором имеется ИЛИ вершина a1 и две подчиненные ей альтернативные вершины b1 и b2. Общим
атрибутом для b1 и b2 является size типа real, специфичный для b1 атрибут – vol
типа real, а специфичный для b2 атрибут – met типа string. Этот фрагмент может
быть описан следующим образом:
ENTITY a1
SUPERTYPE OF (ONEOF (b1,b2));
size: REAL;
END_ENTITY;
ENTITY b1
SUBTYPE OF (a1);
vol: REAL;
END_ENTITY;
ENTITY b2
SUBTYPE OF (a1);
met: STRING;
END_ENTITY;
Используются также следующие правила записи супертипов и подтипов:
• в случае, если a1 есть И вершина, вместо oneof используется зарезервированное слово and (в более общем случае andor), т.е. вторая строчка примера будет
выглядеть так: supertype of (b1 and b2);
• если между подтипами нет взаимосвязи, выражаемой логической функцией
(в частности, ИЛИ или И вершинами), то указание в a1 факта, что это супертип,
не требуется; достаточно упоминание о подчиненности подтипов в их декларациях
в виде subtype of (a1);
• перед декларацией supertype записывается зарезервированное слово abstract,
если вершине a1 не соответствуют какие-либо экземпляры сущности, т. е. если a1
введена только для указания общих для подтипов атрибутов;
96
• у одного подтипа может быть больше одного супертипа; подтип наследует
атрибуты всех своих супертипов; если в декларациях супертипов используются
одинаковые идентификаторы атрибутов, то ссылка на них должна быть в виде составного идентификатора, например: a1.size.
Пример 1
ENTITY device
SUPERTYPE OF (ONEOF (transistor, diode));
(* device есть ИЛИ вершина (И-ИЛИ)-дерева с двумя альтернативами
transistor и diode *)
END_ENTITY;
ENTITY transistor
SUBTYPE OF (device);
b: REAL;
END_ENTITY;
ENTITY diode
SUBTYPE OF (device);
r: REAL;
END_ENTITY;
3.4.3. ЯЗЫК EXPRESS: ОГРАНИЧЕНИЯ
Ограничения, накладываемые на экземпляры сущности, выражаются с помощью правил (rules). Правила могут быть общими или локальными.
Описание правила, общего для ряда сущностей, начинается со служебного
слова rule, далее следует идентификатор правила, служебное слово for, ссылки на
сущности, на которые правило распространяется, и, наконец, собственно ограничения.
Локальные правила могут описывать ключевые атрибуты (uniqueness rules)
или выражать ограничения, накладываемые на атрибуты некоторой сущности
(domain rules). Например, если ключевой атрибут сущности Z есть составной атрибут X.Y, или, другими словами, одному сочетанию значений атрибутов X и Y должен соответствовать единственный экземпляр сущности Z, то
ENTITY Z;
X: INTEGER;
Y: STRING;
UNIQUE
X,Y;
END_ENTITY;
Ограничение на атрибуты некоторой сущности выражается с помощью правила в теле этой сущности. Ограничение записывается после слова where в виде
выражения, значениями которого могут быть true, false или unknown. Допустимыми значениями атрибута будут только те, для которых выражение принимает значение true. Например, можно записать, что длина вектора vect = (x,y,z) должна
быть равна единице, в виде правила cons:
97
ENTITY vect;
x,y,z: REAL;
WHERE
cons: x**2 + y**2 + z**2 = 1.0;
END_ENTITY;
Ограничение where можно использовать в опредляемых типах, например:
TYPE size = REAL;
WHERE SELF < 12.0;
END_TYPE;
Здесь служебное слово SELF заменяет идентификатор определяемого типа,
т. е. в данном примере значения size должны быть меньше 12.
Пример 1
ENTITY date;
day: INTEGER; month: months;
year: INTEGER;
WHERE
days_ok: {1 <= day <= 31};
year_ok: year>0;
date_ok: valid_date(SELF);
END_ENTITY;
3.4.4. ЯЗЫК EXPRESS: ПРОЦЕДУРЫ И ФУНКЦИИ
Процедуры и функции в языке Express служат для описания процедурной
части модели. Как и в алгоритмических языках, используется концепция формальных и фактических параметров. Описание процедуры начинается с служебного
слова procedure, за которым следуют идентификатор процедуры и описание формальных параметров в круглых скобках. Пример описания заголовка процедуры:
PROCEDURE eq (x,y: REAL; n: INTEGER; VAR RESULT: route);
Аналогично описываются функции, их отличает только описание в заголовке
типа результата после закрывающей скобки:
FUNCTION log (a: REAL; m: INTEGER): REAL;
Локальные переменные, описанные в блоке, действуют только в пределах
данных функции или процедуры:
LOCAL
...
END_LOCAL;
Ряд функций и процедур относится к стандартным и потому не требует описания во вновь разрабатываемых моделях. Отметим следующие стандартные
функции: Abs – абсолютная величина; Sqrt – корень квадратный; Exp – экспонента; Log, Log2, Log10 – логарифмы натуральный, двоичный, десятичный соответст98
венно; Sin, Cos, Tan, Acos, Asin, Atan – тригонометрические и обратные тригонометрические функции sin, cos, tg, arccos, arcsin, arctg.
В число стандартных входят также функции: BLength – подсчет числа бит
в двоичном коде; HiBound – верхняя граница индекса у array или верхняя граница
числа элементов у set, bag, list; LoBound – то же в отношении нижних границ;
Length – подсчет числа символов в строке; Odd – возвращает значение true, если
аргумент – нечетное число; SizeOf – возвращает число элементов в объекте агрегативного типа; TypeOf – возвращает список типов, к которым принадлежит параметр этой функции; Exists – возвращает значение true, если аргумент этой функции
входит в число атрибутов соответствующей сущности, и др.
К стандартным процедурам относятся процедуры Insert и Remove – вставка
или изъятие элемента в заданной позиции у объекта агрегативного типа соответственно.
При описании алгоритмов в телах процедур и функций могут использоваться
операторы: пустой (Null), присваивания (Assignment), выбора (Case), составной
(Compound Statement), условный (if..then..else), цикла (Repeat), выхода из функции
или процедуры (Return), перехода на конец цикла (Skip).
В выражениях используются операнды, знаки операций, вызовы функций.
Так, для арифметических операций над числами типа real применяются следующие
знаки: * – умножение, / – деление, DIV – целочисленное деление, + – сложение, –
– вычитание, ** – возведение в степень, MOD – деление по модулю.
Знаки логических операций: not – отрицание, and – конъюнкция, or – дизъюнкция, xor – исключающее ИЛИ. В применении к величинам типа logical эти
операции выполняются по правилам действий в трехзначном алфавите. Логическое
выражение a1 in a2 принимает значение true, если a1 содержится в a2. Оператор
like используется для посимвольного сравнения строк. Знаки отношений: равно =,
не равно <>, больше >, меньше <, больше или равно >=, меньше или равно <=.
Для сравнения экземпляров сущностей используют операции «равно» и «не равно»
со знаками = и <> соответственно.
Операции над множествами (типами bag и set) – пересечение (Intersection),
объединение (Union), разность (Difference). Их знаки суть * (умножение), +
(плюс), – (минус) соответственно. Оператор Query (A <* B | C) возвращает подмножество тех элементов из агрегативного типа B, для которых выполняется условие C, здесь A – простая переменная, используемая в C.
Знак + (плюс) по отношению к операндам типа binary или string есть знак
конкатенации.
В качестве формальных параметров процедур и функций, кроме типов данных, применяемых в других конструкциях языка и охарактеризованных выше, могут использоваться обобщенные типы: generic, aggregate и некоторые другие. Тип
generic формального параметра означает, что соответствующий фактический
параметр может иметь любой тип данных из числа предусмотренных при описании
процедуры. Аналогично тип aggregate обобщает агрегативные типы данных – array,
bag, list, set.
99
Пример 1
FUNCTION add (a,b: GENERIC: intype): GENERIC: intype;
LOCAL
nr: number;
vr: vector;
END_LOCAL;
IF ('number' IN TYPEOF (a)) AND ('number' IN TYPEOF (b))
THEN nr := a+b;
(* функция typeof (a) возвращает тип аргумента а и,
если этот тип есть number, то первый операнд логического выражения
равен true *)
RETURN (nr);
ELSE
IF ('this schema.vector' IN TYPEOF (a)) AND ('this schema.vector' IN
TYPEOF (b)) THEN
vr.i := a.i + b.i;
vr.j := a.j + b.j;
vr.k := a.k + b.k;
(* подразумевается, что декларация типа vector
была произведена в схеме с именем this schema *)
RETURN (vr);
END_IF;
END_IF;
END_FUNCTION;
В языке Express-G специальные символы для изображения правил, процедур
и функций не оговорены.
3.4.5. EXPRESS-X
Семантически эквивалентные прикладные объекты и элементы могут фигурировать в разных моделях. Естественно, что авторы этих моделей, работающие независимо друг от друга, могут использовать разные средства для их описания (например, разные идентификаторы). Если же независимо созданные модели потребуется использовать совместно и соединить в некоторой общей модели, то
необходимо описать имеющиеся соответствия параметров. Для таких описаний
разработан язык Express-X, вошедший в качестве стандарта ISO 10303-14 в лингвистическое обеспечение STEP.
Приводимый ниже пример характеризует способ установления соответствия
между сущностями и атрибутами двух моделей на языке Express.
SCHEMA Old_data;
ENTITY Metadata;
faculty : STRING;
lecturer : STRING;
volume : STRING;
100
annotation : STRING;
END_ENTITY;
ENTITY Subject;
name : STRING;
info: Metadata;
END_ENTITY;
END_SCHEMA;
SCHEMA New_data;
ENTITY Course;
title : STRING;
tutor : STRING;
preface : STRING;
END_ENTITY;
END_SCHEMA;
SCHEMA_Map Data_Mapping;
GLOBAL
DECLARE source INSTANCE OF SOURCE_SCHEMA Old_data;
DECLARE target INSTANCE OF TARGET_SCHEMA New_data;
END_GLOBAL;
MAP lecture FOR tgtInstance:target::Course;
FROM (srcInstance:source::Subject)WHEN TRUE;
BEGIN_MAP
tgtInstance.title := srcInstance.name;
tgtInstance.tutor := srcInstance.info.lecturer;
tgtInstance.preface := srcInstance.info.annotation;
END_MAP;
END_SCHEMA_MAP;
3.4.6. РАСШИРЕНИЯ ЯЗЫКА EXPRESS
Расширение возможностей языка Express достигается путем введения его разновидностей. Так, в языке Express-C добавляются возможности описания событий
и транзакций:
EVENT a;
WHEN b => c; (* здесь b – логическое выражение, с – обращение
к транзакции при b = true *)
END_EVENT;
TRANSACTION c;
LOCAL d: e;
END_LOCAL;
...
END_TRANSACTION;
101
При описании соответствия между двумя Express-моделями используются
языки Express-X или Express-M. Например, в Express-M соответствие между схемой-источником A, в которой заданы атрибуты a1, a2, a3, и схемой-целью B, в которой те же атрибуты описаны идентификаторами b1, b2, b3, выражается следующим описанием:
SCHEMA map B A;
b1 := a1;
b2 := a2;
b3 := a3;
END_SCHEMA map;
При отображении возможны преобразования атрибутов, например, если а1
задан в метрах, а b1 в сантиметрах, то в примере нужно записать b1 := a1*100.
Для обмена конкретными значениями атрибутов между системами используются обменные файлы, структура которых задана стандартом ISO 10303, том 21.
3.4.7. ПРИМЕРЫ МОДЕЛЕЙ НА ЯЗЫКЕ EXPRESS
Пример 1. Пример модели «person_organization_schema», взятый из 41-го тома «Интегрированные ресурсы» стандарта STEP (ISO 10303.41), на языке Express:
SCHEMA person_organization_schema;
ENTITY address;
internal_location : optional label;
street_number : optional label;
street : optional label;
postal_box : optional label;
town : optional label;
region : optional label;
postal_code : optional label;
country : optional label;
facsimile_number : optional label;
telephone_number : optional label;
electronic_mail+address : optional label;
telex_number : optional label;
WHERE
wr1 : EXISTS(internal_location) OR EXISTS(street_number) OR EXISTS(street)
OR EXISTS(postal_box) OR EXISTS(town) OR EXISTS(region)
OR EXISTS(postal_code)
OR EXISTS(country) OR EXISTS(facsimile_number) OR EXISTS(telephone_number)
OR EXISTS(electronic_mail_address) OR EXISTS(telex_number);
END_ENTITY;
ENTITY personal_address
SUBTYPE OF (address);
102
people : SET[1:?] OF person;
description : text;
END_ENTITY;
ENTITY person;
id : identifier;
last_name : OPTIONAL label;
first_name : OPTIONAL label;
middle_names : OPTIONAL LIST[1:?] OF label;
prefix_titles : OPTIONAL LIST[1:?] OF label;
suffix_titles : OPTIONAL LIST[1:?] OF label;
UNIQUE
ur1 : id;
WHERE
wr1 : exists(last_name) OR exists(first_name);
END_ENTITY;
END_SCHEMA;
Пример 2. Пример использования языка Express-G для представления модели
«Определение изделия» из стандарта ISO 10303-41 показан на рис. 3.19.
Рис. 3.19. Пример модели «Определение изделия» на языке
Express-G
Примеры применения языка Express для детали, схемы, моделей представлены в приложении.
103
3.5. ЗАРУБЕЖНЫЕ СТАНДАРТЫ
Стандарты Parametrics введены сравнительно недавно (1996 г.) в связи с тем,
что стандарты STEP в недостаточной мере учитывали особенности современных
САПР в части представления параметризованных моделей изделий и обмена параметризованными данными.
Рабочая группа ISO по Parametrics решает как краткосрочные, так и перспективные задачи. Первые из них касаются удовлетворения потребностей геометрического проектирования и машинной графики в сегодняшних САПР, в которых широко используются параметризованные модели. Вторые касаются попыток распространения идей параметризации на более ранние этапы проектирования и на более
широкий круг моделей и процедур проектирования, имеющих не только геометрический характер.
AECMA 1000D – International specification for technical publications utilizing a
Common Source Data Base – Международная спецификация требований к техническим руководствам, выполняемым с использованием общей базы данных. Спецификация разработана Европейской ассоциацией аэрокосмической промышленности (the European Association of Aerospace Industries – AECMA). В спецификации
изложена технология работ по подготовке и сопровождению эксплуатационной
технической документации AECMA Specification 2000M (см. главу 5. «Интегрированная логистическая поддержка»).
Любая продукция включает в себя компоненты и комплектующие изделия,
получаемые от поставщиков. Одновременно одни и те же компоненты и комплектующие могут входить в разную продукцию, поэтому существует потребность
в средствах их самостоятельного информационного описания.
ISO 13584 Parts Library (PLIB) – это серия международных стандартов
для представления и обмена доступными для компьютерной интерпретации данными о поставляемых компонентах и комплектующих изделиях (узлах, деталях).
В этих стандартах представлены в виде библиотек данные о семействах таких типовых широко используемых компонентов изделий, как болты, подшипники, электронные компоненты и т. п., с целью использования этих данных в различных системах автоматизированного проектирования. В PLIB содержатся также правила
использования, интерфейса и модификации библиотечных описаний. Цель стандарта – обеспечить инвариантный для приложений механизм оперирования частями библиотеки.
Благодаря ISO 13584 различные прикладные САПР могут разделять данные из
обобщенных баз данных, беспрепятственно обмениваться данными о типовых
компонентах. Описание библиотечных моделей дается на языке Express. Для описания структуры частей, вводимых определений и других текстовых фрагментов
используется язык SGML. Поведенческие модели электронных компонентов могут
быть выражены с помощью языка VHDL.
Стандарт ISO 13584 PLIB включает семь разделов:
• общий обзор и основополагающие принципы;
• концептуальная модель библиотеки деталей;
104
• интегрированные ресурсы;
• логическая модель библиотеки поставщика;
• данные о поставщике;
• программный интерфейс к данным;
• методология структуризации классов (семейств) деталей.
Стандарт ISO 13584 PLIB регламентирует:
средства описания и технологию представления информации о компонентах
и комплектующих;
технологию обработки данных, в том числе хранения, передачи, доступа, изменения и архивирования.
В отличие от стандарта ISO 10303 STEP, предназначенного для описания конкретного экземпляра продукции, стандарт ISO 13584 PLIB позволяет описывать
классы продукции (компонентов и комплектующих):
• детали, определенные международными или национальными стандартами
(например, крепежные детали, уплотнения, подшипники);
• библиотеки (базы) данных о деталях конкретного поставщика.
В процессах проектирования обмен данными о деталях и комплектующих,
например между системами проектирования А и В, может иметь два контекста:
• обмен метаданными (данными об информационных моделях деталей);
• обмен собственно данными о деталях.
В последнем случае должен использоваться стандарт ISO 10303 STEP.
Стандарты ISO 15531 MANDATE посвящены представлению данных, относящихся к функционированию предприятий, управлению территориально распределенными производственными системами, обмену данными о производстве
с внешней для предприятия средой, регламентируют некоторые вопросы представления производственных данных. Областью стандартизации является форма представления и методы использования информации о производстве и используемых
производственных ресурсах, их характеристиках и ограничениях.
Часть стандарта, обозначаемая ISO 15531-21, содержит обзор и основные
принципы представления данных о промышленной продукции. Содержание этой
части характеризуется следующими ключевыми словами: системы промышленной
автоматизации и интеграция, промышленные данные, обмен данными об управлении производством, обмен данными с внешней средой.
Том ISO 15531-31 посвящен обзору и основным принципам использования
данных о производственных ресурсах. Излагается модель, форма и атрибуты представления данных о производственных ресурсах, об управлении их применением.
Том ISO 15531-41 содержит обзор и основные принципы управления потоками производственных данных.
Как видно из приведенных примеров, стандарт MANDATE так же, как
и STEP, имеет сложную структуру. Он состоит из трех разделов:
• представление производственных данных для внешнего обмена;
• данные для управления использованием производственных ресурсов;
• данные для управления производственными потоками.
Каждый раздел, в свою очередь, состоит из нескольких томов.
105
Первый раздел определяет требования к обмену производственной информацией между компаниями на основе использования протоколов электронного обмена данными – EDI (Electronic Data Interchange). Особое внимание уделено:
• данным, которыми обменивается между собой коммерческая и производственная сферы;
• информации, необходимой для планирования производства;
• информации, содержащейся в получаемых заказах;
• информации, получаемой из сферы закупок;
• информации, необходимой для управления поставщиками и дочерними компаниями;
• информации, необходимой для приема и распределения изделий.
Второй раздел посвящен представлению данных по управлению использованием производственных ресурсов (оборудования, энергоснабжения, транспорта
и пр.). Сюда относится описание и характеристики ресурсов, управление работой
промышленного оборудования, вопросы качества, обслуживания и безопасности.
Описание производственных ресурсов может быть представлено в виде баз данных, содержащих параметры ресурсов, входы и выходы ресурсов, объем и мощность ресурсов, прикладное программное обеспечение, степень внутреннего
управления и уровень интеллектуальности используемых ресурсов, ссылки
на стандартные ресурсы, планы работы и управление обслуживанием, данные о
стоимости использования ресурсов и т. д.
Третий раздел касается данных по управлению производственными потоками и содержит данные о материальных потоках в дискретном производстве, а также информацию, необходимую для планирования, управления и мониторинга потоков материалов. В разделе рассматриваются вопросы определения объемов производства, управления производством, планирования производства и потребности
в ресурсах, работы по схеме «точно во время» (Just in Time), оптимизации технологии производства, оценки планов, мониторинга производства, учета стоимости,
планирования процессов, спецификации изделий.
Стандарт США FIPS 183 регламентирует порядок и правила функционального моделирования бизнес-процессов на основе методологии IDEF/0. Эта методология используется для создания функциональной модели (ФМ), отображающей
процессы и функции системы, а также потоки информации и материальных объектов, преобразуемые этими функциями. Стандарт фиксирует требования к графическому языку компьютерного отображения функциональных моделей, его синтаксис и семантику. Простота и наглядность этого языка привели к тому, что стандарт
de-facto стал международным.
Инициатива PLCS. В рамках данной концепции трудно дать сколько-нибудь
полный перечень международных и национальных стандартов, относящихся к рассматриваемой проблематике. Поэтому в заключение приведенного выше краткого
обзора можно лишь упомянуть инициативу 14 ведущих промышленных компаний,
поддержанную рядом правительственных организаций и названную PLCS (Product Life Cycle Support).
106
Участников инициативы PLCS не удовлетворяют темпы стандартизации, качество и стоимость информации. Эта инициатива реализуется силами специализированной команды в составе рабочей группы Технического комитета ISO/TC184
(полное обозначение ISO/TC184/SC4/WG3/T8). Основная цель инициативы – ускорить разработку и развитие новых стандартов обмена надежной информацией
о комплексах (сложных технических системах) и сопровождении их эксплуатации,
т. е. информацией, необходимой и получаемой в процессе создания, изготовления,
эксплуатации и модернизации комплекса вплоть до снятия с эксплуатации.
Этот международный проект создан для выработки согласованного стандарта
на основе радикального расширения стандарта ISO 10303 обмена данными о модели продукта, известного под аббревиатурой STEP. Предполагается, что в рамках
инициативы PLCS будет обеспечено более раннее привлечение разработчиков специализированных программных продуктов, реализующих требования стандартов.
Цели и сфера проводимых в рамках инициативы PLCS работ схематично
представлены на рис. 3.20 и направлены на обеспечение получения наиболее полных и актуальных данных в течение полного жизненного цикла комплекса.
Приведенный рисунок свидетельствует о полноте компонентов системы IFS
Applications для реализации потребностей PLCS.
Рис. 3.20. Инициатива управления жизненным циклом комплекса (PLCS)
и ее комплексное покрытие компонентами IFS Applications
107
Базовый стандарт на представление текстовой и графической информации. Основным стандартом, регламентирующим представление в документах текстовой и графической информации, а также рационального управления документом (определение логической структуры внутри документа, т. е. связей различных
элементов информации друг с другом) является международный стандарт ISO
8879 Information Processing Text and Office System – Standard Generalized Markup
Language (SGML). Этот стандарт определяет обобщенный стандартный язык разметки текста, способ описания структуры документа, а также формат вставляемых
в документ описательных меток.
С точки зрения стандарта SGML документ рассматривается как совокупность:
• содержания (информации, содержащейся в документе в текстовой, графической и мультимедийной форме);
• данных о структуре документа (взаимосвязи глав, разделов, параграфов,
ссылки, права доступа к элементам документа);
• данных о стиле оформления документа (используемых шрифтах, интервалах, размерах полей, способе нумерации и т.д.).
Структура документа задается при помощи «Определения типа документа»
(ОТД, DTD – Document Type Definition), описывающего эту структуру подобно
тому, как схема базы данных описывает типы поддерживаемых данных и отношения между полями. ОТД задает взаимосвязь фрагментов текста, образующих документ, а также может быть определен как шаблон, который определяет, какая информация доступна и где.
В ОТД указывают соответствие символов и их кодов, максимальные длины
используемых идентификаторов, способ представления ограничителей для тегов,
другие возможные соглашения, синтаксис ОТД, а также тип и версию документа.
Следовательно, SGML можно назвать метаязыком для семейства конкретных
языков разметки. В частности, подмножествами SGML можно считать языки разметки XML и HTML. При этом XML более удобен, чем SGML: легче воспринимается, приспособлен для использования в WWW (современных браузерах), сохраняя
возможности SGML. Для конкретных приложений создаются свои варианты (словари) XML. Известны варианты для математики, химии, медицины. Для CALS интерес представляет вариант Product Definition eXchange (PDX), посвященный обмену данными.
При обмене документами, основанными на SGML ОТД, для удостоверения
правильности логической структуры может использоваться следующий подход:
• ОТД для требуемого типа документа передается поставщику информации.
• Поставщик, создавая информацию, при проверке документа следует соответственно определенному ОТД, используя программное обеспечение, называемое
синтаксическим анализатором.
• Информация поставляется заказчику.
• Заказчик, проверяя соответствие описания информации определенному
ОТД, проверяет документ, используя программное обеспечение, называемое синтаксическим анализатором.
108
• Если информация не соответствует принятому формату, она возвращается
обратно поставщику для завершения или переработки.
Таким образом, можно автоматически гарантировать, что в документ включена вся информация и что она структурирована согласно требованиям.
Применение стандарта SGML для создания структурированных документов
дает значительные преимущества:
• Структурный подход позволяет создателю документа организовать информацию и хранить его содержание отдельно от формата. Это помогает централизованно настроить формат документов, поэтому их авторы могут сосредотачивать
свои усилия на содержании, а не на оформлении, что удваивает производительность.
• Печатный документ – только одна форма информации, основанная на SGML.
Например, группа технических публикаций может использовать метки для идентификации процедуры, состоящей из последовательных задач. Здесь идентифицируются начало и конец процедуры и каждый ее шаг. Результат способен проявиться в нескольких формах: руководства по поддержке и работе, технического руководства в режиме онлайн, пособия по обучению и т. д. Более того, поскольку метки
доступны для компьютерной интерпретации, управлять режимами и обеспечить
различное применение информации из одного источника сможет компьютер.
• Поскольку SGML – простой стандартный формат файла, то не придется заново конвертировать документы, когда аппаратное и программное обеспечения
выйдут из употребления.
• Структура документа проверяет, находится ли необходимая информация
в нужном месте. Поскольку SGML исключает трансляцию данных, нет риска потерять информацию при ее переводе из одного формата в другой.
• Используя SGML, манипулируют элементами информации. Помеченный
элемент может иметь атрибуты, определяющие его характеристики или свойства.
Информация, содержащаяся в атрибутах, не предназначена для печати, но помогает при управлении элементами данных. Например, атрибут ID (идентификатор)
уникальным образом идентифицирует единичный параграф, целую секцию, примечание, иллюстрации, задачу или любой элемент. Поскольку идентификаторы ID
доступны для компьютерной интерполяции, они могут связывать информацию
и использоваться для различных видов управления ею. Это помогает:
– управлять защитой информации, позволяя видеть ее только отдельным людям, которым разрешен доступ;
– управлять потоками информации (например, изменение данных в одном
месте вызывает изменение тех же данных в других приложениях).
• Поскольку SGML работает с компонентами структурированных документов,
то можно создавать документы, используя информацию, полученную из разных
источников. Это дает возможность пользователям иметь разделенный доступ к самой последней версии данных без дублирования. Примером служит стандартная
запись copyright в документах всей компании. Правовой отдел управляет информационным модулем, при необходимости изменяя его. В документ включается
единственная метка, идентифицирующая запись в ее текущем состоянии, и эту запись можно распечатывать в любом количестве публикаций.
109
• В настоящее время при использовании стандарта SGML различными компьютерами, операционными системами и приложениями информации в раздельном режиме употребляются информационные сети. В таких сетях переносимость
информации становится ключевым вопросом в обеспечении доступа к ней. Документы SGML вследствие программной и аппаратной зависимости легко транслируются в разные системы.
Стандарту ISO 8879 сопутствуют дополнительные технические стандарты,
как международные, так и национальные, регламентирующие различные аспекты
его использования. К их числу относятся:
• ISO/IEC 10179 Document Style Semantics and Specification Language
(DSSSL). Данный стандарт определяет язык для описания правил и формата отображения SGML-документов при выводе на экран, печать или иное устройство
отображения.
• ISO/IEC IS 10744 Information Technology – Hypermedia Time Based Document Structuring Language (HyTime). Определяет расширение SGML в части использования мультимедийной информации.
• ISO/IEC 8632 Information Processing Systems – Computer Graphics – Metafile.
Стандарт описывает формат хранения планарных векторных и векторно-растровых
изображений. Сформулированы требования к представлению изображений в формате CGM.
• ISO/IEC 10918 Coding of Digital Continuous Tone Still Picture Images (JPEG).
Стандарт определяет требования к представлению растровой графики в цифровом
формате.
• ISO 11172 MPEG2 Motion Picture Experts Group (MPEG) Coding of Motion
Pictures and associated Audio for Digital Storage Media. Стандарт определяет требования к представлению видеоинформации в цифровом формате.
• ISO/IECS 13522 Information Technology – Coding of Multimedia and Hypermedia Information (MHEG). Определяет требования к представлению мультимедийной информации.
• MIL-HDBK-28001 US Department of Defence Application of – SGML. Federal
Information Processing Standard (FIPS 152). В этом стандарте США, одновременно
являющимся и стандартом министерства обороны, описаны принципы использования языка SGML для составления технической документации. Приводятся руководства по хранению, извлечению, обмену и обработке данных, подготовленных
в соответствии с требованиями данного документа. Содержится описание роли
языка SGML в общей стратегии CALS. Также документ содержит описания процедур анализа документов, разработки описаний типа документа (DTD), создания
экземпляров документации, SGML-маркировки сложных данных (таких как математические формулы). В приложениях к стандарту приведены схемы построения
систем хранения технической информации, механизмы обновления и корректировки данных.
Спецификация AECMA S1000D – технология представления технической документации, признанная в авиационной промышленности AECMA. Кроме
стандартизации перечня информации предметной области стандарт регламентирует
110
определение общей базы данных эксплуатационной документации. Основная цель
общей базы данных заключается в предоставлении исходной информации для создания технической публикации. Документация может быть определена как данным
стандартом, так и любой другой гражданской или военной спецификацией. База
данных также предназначена для использования в электронной логистической информационной системе для передачи информационных модулей напрямую их потребителям (пользователям). Такие модули могут быть также интерактивными.
Данный аспект использования отражен в самом названии базы данных – общая
база данных эксплуатационной документации. Оно подразумевает, что регламентируемая стандартом информация должна использоваться как производителями,
так и покупателями и эксплуатантами военных и гражданских воздушных судов.
В основе AECMA S1000D, как и в старших классах ИЭТР, лежит декомпозиция представляемого материала на модули. Модули включают идентификационную и содержательную секции, записанные на языках SGML или HyTime с иллюстрациями в форматах CGM или JPEG, и хранятся в специальной БД – Common
Source Data Base (CSDB). Предусмотрена автоматическая простановка гиперссылок (для этого имеются соответствующие программные средства).
Предусмотрены модули нескольких типов:
– описание устройства и принципов работы изделия;
– каталог деталей и сборочных единиц.
Регламент технического обслуживания включает перечень типов работ
со ссылками на соответствующие технологические карты:
– правила выполнения процедур технического обслуживания;
– возможные неисправности и способы их устранения;
– инструкции для оператора.
• MIL-STD-1840 – стандарт Министерства обороны США – Автоматизированный обмен технической информацией (Automated Interchange of Technical Information) – часто называют «зонтичным» стандартом в области CALS-технологий,
т. к. он определяет используемые международные, национальные, военные стандарты и спецификации для электронного обмена информацией между организациями или системами.
• MIL-STD-1840C посвящен представлению и обмену данными в CALS-технологиях. Основные положения этого стандарта признаны в России и представлены в документе Р50.1.027-2001. Стандарт определяет международные, национальные, военные стандарты и спецификации для электронного обмена информацией
между организациями или системами. В нем к стандартам и спецификациям технологий CALS отнесен ряд стандартов таких, как вышеназванные стандарты STEP,
SGML, а также стандарты шифрования данных и электронной подписи, кодирования, аудио- и видеоданных, спецификации MIME электронной почты и т. п.
Он определяет формат, структуру и методы обмена техническими данными
в разнородной компьютерной среде, т. е. данными, используемыми для преобразования и хранения технической информации в электронном виде. Под термином
«технические данные» понимается информация, используемая системами автоматизированного проектирования, управления, планирования и т. д.
111
В соответствии с MIL-STD-1840C документы могут быть SGML-документами, обменными файлами на языке Express, для представления иллюстраций
и текста допускается использование ряда других форматов. Так, для передачи
и представления в технических руководствах иллюстративного материала (схем,
рисунков) в соответствии с американским стандартом MIL-PRF-28003 можно использовать формат BMP, но более экономичен формат JPEG. Для 2D чертежей
(но не в САПР) рекомендуется использовать формат CGM (Computer Graphics
Metafile), ранее введенный в ISO/IEC 8632. Растеризация выполняется в соответствии с рекомендацией MIL-PRF-28002. Стандартный растровый формат – TIFF. Отметим, что документы MIL-PRF-28000 и MIL-PRF-28001 посвящены соответственно форматам IGES и SGML. Формат IGES (Initial Graphics Exchange
Specification), утвержденный в качестве стандарта в начале 80-х гг., был предшественником STEP, но он был ориентированным в основном на описание геометрических свойств изделий.
В структуре документа выделяют реквизитную и содержательную части.
В реквизитной части записываются метаданные в виде списка идентификаторов
атрибутов и их значений, а также сведения об электронных подписях документа.
Содержательная часть состоит из одного или более блоков данных, каждый блок
имеет собственно передаваемые данные и их описание.
Особенности проектирования радиоэлектронной аппаратуры находят отражение и в форматах обмена данными. Основные методики функционального и логического проектирования электронных устройств основаны на использовании
языка VHDL (Very high-speed integrated circuits Hardware Design Language), получившего статус международного стандарта IEEE 1076 в 1987 г. При конструкторском проектировании для описания топологии СБИС и печатных плат широко
применяются форматы EDIF (Electronic Design Interchange Format) и CIF (Caltech
Intermediate Format).
Развитие методологии моделирования на базе языка VHDL привело в 1999 г.
к принятию стандарта IEEE 1076.1, посвященного смешанному (mixed mode) моделированию. Отметим, что смешанным принято называть аналого-цифровое моделирование, т. е. исследование моделей, в которых используются как непрерывные, так и дискретные величины. Объединение стандартов IEEE 1076 и 1076.1
в одном документе VHDL-AMS (VHDL Analog and Mixed Signal) позволило унифицировать описание моделей не только систем электрической природы, но также
систем механических, гидравлических, тепловых и систем с физически разнородными компонентами.
Жизненный цикл систем описывается в стандарте ISO/IEC 15288, жизненный
цикл ПО – в ISO/IEC 12207, обследование процессов – в ISO/IEC 15504.
Название стандарта ISO/IEC 15288 – «Системная инженерия – Процессы
жизненного цикла систем». Стандарт описывает общую структуру процессов, составляющих жизненный цикл любого рода систем, созданных человеком. Основное внимание уделено вопросам непрерывной оценки качества систем, контроля
качества циркулирующей информации, управления рисками, анализа рисков
и оптимизации процессов на всех стадиях разработки и эксплуатации систем.
112
Управление рисками подразумевает определение событий, которые отрицательно влияют на систему, проект или организацию, оценку рисков и их обработку. Оценка производится в терминах и показателях качества, затрат, сроков или
технических характеристик. Решение проблем управления рисками базируется
на моделировании.
Основные зарубежные стандарты представлены в табл. 3.2.
Таблица 3.2
ЗАРУБЕЖНЫЕ СТАНДАРТЫ В ОБЛАСТИ CALS
№
п/п
Номер стандарта
1
1
2
3
2
AQAP-150
AQAP-159
AQAP-160
4
AQAP-2000
5
DEF STAN 00-60
Part 0/5
DEF STAN 00-60
Part 0/5
Приложения
DEF STAN 00-60
Part 0/6
DEF STAN 00-60
Part 1/2
DEF STAN 00-60
Part 1/3
DEF STAN 00-60
Part 10/5
DEF STAN 00-60
Part 2/5
DEF STAN 00-60
Part 20/6
DEF STAN 00-60
Part 20/7
DEF STAN 00-60
Part 21/5
DEF STAN 00-60
Part 21/6
DEF STAN 00-60
Part 22/5
DEF STAN 00-60
Part 23/2
DEF STAN 00-60
Part 24/5
DEF STAN 00-60
Part 25/2
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Наименование
3
Требования НАТО для обеспечения качества программного обеспечения
Руководство к использованию AQAP-150
Интегрированные требования НАТО к качеству программного
обеспечения в течение жизненного цикла
Политика НАТО в области интегрированного системного подхода
к качеству на стадиях жизненного цикла
Интегрированная логистическая поддержка.
Часть 0: Применение интегрированной логистической поддержки (ИЛП)
Интегрированная логистическая поддержка.
Часть 0: Применение интегрированной логистической поддержки (ИЛП).
Приложения.
Интегрированная логистическая поддержка. Часть 0: Применение
интегрированной логистической поддержки (ИЛП)
Интегрированная логистическая поддержка. Часть 1: Анализ
логистической поддержки и записи об анализе логистической поддержки
Интегрированная логистическая поддержка. Часть 1: Анализ
логистической поддержки и записи об анализе логистической поддержки
Интегрированная логистическая поддержка.
Часть 10: Электронная документация
Интегрированная логистическая поддержка.
Часть 2: Руководство по применению LSA и LSAR
Интегрированная логистическая поддержка.
Часть 20: Применение интегрируемых процедур поставки
Интегрированная логистическая поддержка.
Часть 20: Применение интегрируемых процедур поставки
Интегрированная логистическая поддержка.
Часть 21: Процедуры для первоначального обеспечения
Интегрированная логистическая поддержка.
Часть 21: Процедуры для первоначального обеспечения
Интегрированная логистическая поддержка.
Часть 22: Процедуры для кодирования
Интегрированная логистическая поддержка.
Часть 23: Процедуры для планирования закупок
Интегрированная логистическая поддержка.
Часть 24: Процедуры для администрирования заказов
Интегрированная логистическая поддержка.
Часть 25: Процедуры для выставления счетов
113
Продолжение табл. 3.2
1
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
114
2
DEF STAN 00-60
Part 26/1
DEF STAN 00-60
Part 3/2
DEF STAN 00-60
Part 3/3
DI-ILSS-80095
DI-ILSS-80391
ISO 11799:2003
3
Интегрированная логистическая поддержка.
Часть 26: Процедуры для администрирования восстановления
Интегрированная логистическая поддержка.
Часть 3: Руководство по применению программной поддержки
Интегрированная логистическая поддержка.
Часть 3: Руководство по применению программной поддержки
План интегрированной логистической поддержки
Ценовой план записи анализа логистической поддержки (LSAR)
Информация и документация.
Требования к хранению архивных и библиотечных материалов
ISO 15188:2001
Руководящие указания по менеджменту проекта стандартизации
терминологии
ISO 15489-1:2001 Информация и документация. Управление записями.
Часть 1. Общие требования
ISO 8439:1990
Бланки. Основная схема составления
ISO/IEC 14598Программирование. Оценка продукта.
2:2000
Часть 2. Планирование и управление
ISO/IEC
Информационная технология.
17799:2005
Практический кодекс по менеджменту информационной безопасности
ISO/IEC TR
Информационная технология. Процессы жизненного цикла программных
15846:1998
средств. Управление конфигурацией
ISO/IEC TR
Проектирование систем – Руководство по применению ISO/IEC 15288
19760:2003
(Процессы жизненного цикла системы)
ISO/TS 23081Информация и документация. Процессы управления записями.
1:2004
Метаданные для записей. Часть 1. Принципы
MIL-D-87269
Базы данных, изменяемые: интерактивные электронные технические
руководства
MIL-DTL-31000
Технические условия. Комплект технической документации
MIL-HDBK-28001 Применение MIL-PRF-28001 с использованием стандартного
обобщенного языка разметки (SGML)
MIL-HDBK-502
Логистика закупок
MIL-HDBK-59
Руководство по осуществлению поддержки CALS
MIL-HDBK-61
Руководство по конфигурации управления
MIL-PRF-28000
Цифровое представление для передачи данных о продукте:
приложения IGES и протоколы приложений IGES
MIL-PRF-28001
Требования разметки и общие стилевые спецификации
для передачи текста и его представления
MIL-PRF-28002
Требования представления растровой графики в бинарном формате
MIL-PRF-28003
Цифровое представление для передачи иллюстраций:
CGM-профиль приложения
MIL-PRF-49506
Информация для логистического менеджмента
MIL-PRF-87268
Интерактивные электронные технические руководства:
общее содержание, стиль, формат и требования взаимодействия
с пользователем
MIL-PRF-87269
Базы данных, изменяемые:
интерактивные электронные технические руководства
Окончание табл. 3.2
47
MIL-Q-87270
48
49
50
51
52
53
54
MIL-STD-1369
MIL-STD-1808
MIL-STD-1840
MIL-STD-2361
MIL-STD-2549
MIL-STD-38784
MIL-STD-974
Программа обеспечения качества: интерактивные электронные
технические руководства и соответствующая техническая информация.
Требования
Требования к программе интегрированной логистической поддержки
Нумерация (кодирование) систем, подсистем
Автоматизированный обмен технической информацией
Разработка электронной документации
Интерфейс данных для конфигурации управления
Стандартная практика для технических руководств
Интегрированные технические информационные услуги подрядчика
В рабочей группе WG10 подкомитета SC4 была предпринята попытка разработки стандарта ISO 18876 «Integration of industrial data for exchange, access, and
sharing» (IIDEAS). Его назначение – обеспечение взаимодействия приложений
и организаций, использующих разные стандарты, интеграция данных и моделей,
получаемых из разных источников, разрабатываемых в разных САПР. Предполагалось согласование моделей, выраженных с помощью разных языков моделирования и форматов, например таких, как SGML, XML, Express. Средства интеграции – специальные интеграционные модели и методы создания, распространения,
обновления моделей, их связи с прикладными протоколами. Предполагалось также, что в IIDEAS будет введен язык EXIST (EXpression of Information based on Set
Theory), более соверешенный, чем Express, учитывающий ряд свойств таких языков, как Unified Modelling Language (UML), Knowledge Interchange Format (KIF),
XML и др. Некоторые свойства EXIST уже рассматривались рабочей группой
WG11 в проекте языка Express-2. Однако к настоящему времени ISO 18876 так
и не появился из-за трудностей реализации проекта.
3.6. СТАНДАРТЫ РОССИИ
Работа по созданию национальных CALS-стандартов проводится в России
под эгидой Госстандарта РФ. Технический комитет ТК431 «CALS-технологии»
разработал ряд стандартов серии ГОСТ Р ИСО 10303, являющихся адекватными
переводами соответствующих международных стандартов.
Госстандартом РФ утверждены следующие 6 томов этого стандарта
(рис. 3.21), и подготовлены к утверждению еще 6:
1. ГОСТ Р ИСО 10303-1-99. Системы автоматизации производства и их интеграция. Представление данных об изделии и обмен этими данными. Часть 1. Общие представления и основополагающие принципы.
2. ГОСТ Р ИСО 10303-21-99. Системы автоматизации производства и их интеграция. Представление данных об изделии и обмен этими данными. Часть 21.
Методы реализации. Кодирование открытым текстом структуры обмена.
3. ГОСТ Р ИСО 10303-41-99. Системы автоматизации производства и их интеграция. Представление данных об изделии и обмен этими данными. Часть 41.
Интегрированные обобщенные ресурсы. Основы описания и поддержки изделий.
115
4. ГОСТ Р ИСО 10303-11-2000. Системы автоматизации производства и их
интеграция. Представление данных об изделии и обмен этими данными. Часть 11.
Методы описания. Справочное руководство по языку Express.
5. ГОСТ Р ИСО 10303-12-2000. Системы автоматизации производства и их
интеграция. Представление данных об изделии и обмен этими данными. Часть
12. Методы описания. Справочное руководство по языку Express-1.
Рис. 3.21. Формирование нормативной базы CALS/ИПИ
6. ГОСТ Р ИСО 10303-45-2000. Системы автоматизации производства и их
интеграция. Представление данных об изделии и обмен этими данными. Часть 45.
Интегрированные обобщенные ресурсы. Материалы.
7. Р 50.1.027-2001. Информационные технологии поддержки жизненного цикла продукции. Автоматизированный обмен технической информацией. Основные
положения и общие требования.
8. Р 50.1.028-2001. Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования.
9. Р 50.1.029-2001. Информационные технологии поддержки жизненного цикла продукции. Интерактивные электронные технические руководства. Общие требования к содержанию, стилю и оформлению.
10. Р 50.1.030-2001. Информационные технологии поддержки жизненного
цикла продукции. Интерактивные электронные технические руководства. Требования к логической структуре базы данных.
11. Р 50.1.031-2001. Информационные технологии поддержки жизненного
цикла продукции. Терминологический словарь. Часть 1. Стадии жизненного цикла
продукции.
12. Р 50.1.032-2001. Информационные технологии поддержки жизненного
цикла продукции. Терминологический словарь. Часть 2. Применение стандартов
серии ГОСТ Р ИСО 10303.
Основные ГОСТы России представлены в табл. 3.3
116
Таблица 3.3
ОСНОВНЫЕ ГОСТЫ РОССИИ В ОБЛАСТИ CALS
№
п/п
Номер стандарта
1
1
2
2
ГОСТ 2.001-93
ГОСТ 2.102-68
3
ГОСТ 2.105-95
4
5
ГОСТ 2.106-96
ГОСТ 22771-77
6
ГОСТ 24.104-85
7
ГОСТ 24.301-80
8
ГОСТ 24.302-80
9
ГОСТ 24.303-80
10
ГОСТ 24.304-82
11
12
ГОСТ 24.401-80
ГОСТ 24.402-80
13
ГОСТ 24.501-82
14
ГОСТ 24.701-86
15
ГОСТ 24.702-85
16
ГОСТ 24.703-85
17
ГОСТ 27596-88
18
ГОСТ 27889-88
19
20
21
ГОСТ 28803-90
ГОСТ 28806-90
ГОСТ 34.003-90
22
ГОСТ 34.201-89
23
ГОСТ 34.320-96
Наименование
3
Единая система конструкторской документации. Общие положения
Единая система конструкторской документации.
Виды и комплектность конструкторских документов
Единая система конструкторской документации.
Общие требования к текстовым документам
Единая система конструкторской документации. Текстовые документы
Автоматизированное проектирование.
Требования к информационному обеспечению
Единая система стандартов автоматизированных систем управления.
Автоматизированные системы управления. Общие требования
Система технической документации на АСУ.
Общие требования к выполнению текстовых документов
Система технической документации на АСУ.
Общие требования к выполнению схем
Система технической документации на АСУ.
Обозначения условные графические технических средств
Система технической документации на АСУ.
Требования к выполнению чертежей
Система технической документации на АСУ. Внесение изменений
Система технической документации на АСУ.
Учет, хранение и обращение
Автоматизированные системы управления дорожным движением.
Общие требования
Единая система стандартов автоматизированных систем управления.
Надежность автоматизированных систем управления.
Основные положения
Единая система стандартов автоматизированных систем управления.
Эффективность АСУ. Основные положения
Единая система стандартов автоматизированных систем управления.
Типовые проектные решения в АСУ. Основные положения
Системы производственные гибкие. Системы транспортно-складские
автоматизированные. Классификация и обозначение
Системы производственные гибкие.
Системы транспортно-складские автоматизированные. Параметры
Обмен данными. Структура идентификации организаций
Качество программных средств. Термины и определения
Информационная технология. Комплекс стандартов
на автоматизированные системы. Термины и определения
Информационная технология. Комплекс стандартов на
автоматизированные системы. Виды, комплектность и обозначение
документов при создании автоматизированных систем
Информационные технологии. Система стандартов по базам данных.
Концепции и терминология для концептуальной схемы
и информационной базы
117
Продолжение табл. 3.3
1
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
118
2
ГОСТ 34.601-90
3
Информационная технология. Комплекс стандартов
на автоматизированные системы. Автоматизированные системы.
Стадии создания
ГОСТ 34.602-89
Информационная технология.
Комплекс стандартов на автоматизированные системы.
Техническое задание на создание автоматизированной системы
ГОСТ 34.603-92
Информационная технология. Виды испытаний автоматизированных
систем
ГОСТ 7.0-99
Система стандартов по информации, библиотечному и издательскому
делу. Информационно-библиотечная деятельность, библиография.
Термины и определения
ГОСТ 7.58-90
Система стандартов по информации, библиотечному и издательскому
делу. Информационное обеспечение программ комплексной
стандартизации продукции. Общие требования
ГОСТ 7.67-2003
Система стандартов по информации, библиотечному и издательскому
делу. Коды названий стран.
ГОСТ 7.67-94
Система стандартов по информации, библиотечному и издательскому
делу. Коды названий стран
ГОСТ 7.70-2003
Система стандартов по информации, библиотечному и издательскому
делу. Описание баз данных и машиночитаемых информационных
массивов. Состав и обозначение характеристик
ГОСТ 7.75-97
Система стандартов по информации, библиотечному и издательскому
делу. Коды наименований языков
ГОСТ ИСО
Система стандартов по информации, библиотечному и издательскому
8601-2001
делу. Представление дат и времени. Общие требования
ГОСТ Р 1.4-93
Государственная система стандартизации Российской Федерации.
Стандарты отраслей, стандарты предприятий, стандарты научнотехнических, инженерных обществ и других общественных организаций.
Общие положения
ГОСТ Р 15.000-94 Система разработки и постановки продукции на производство.
Основные положения
ГОСТ Р 34.10Информационная технология. Криптографическая защита информации.
2001
Процессы формирования и проверки электронной цифровой подписи
ГОСТ
Информационная технология. Промышленная автоматизация. Основное
Р 34.1501.1-92
производство. Часть 1. Эталонная модель стандартизации и методология
идентификации требований к стандартизации
ГОСТ Р 51167-98 Качество служебной информации. Графические модели технологических
процессов переработки данных
ГОСТ Р 51168-98 Качество служебной информации. Условные обозначения элементов
технологических процессов переработки данных
ГОСТ Р 51169-98 Качество служебной информации. Система сертификации
информационных технологий в области качества служебной
информации. Термины и определения
ГОСТ 27596-88
Системы производственные гибкие.
Системы транспортно-складские автоматизированные.
Классификация и обозначение
ГОСТ 27889-88
Системы производственные гибкие.
Системы транспортно-складские автоматизированные. Параметры
Продолжение табл. 3.3
1
43
44
45
2
ГОСТ 28803-90
ГОСТ 28806-90
ГОСТ 34.003-90
46
47
ГОСТ Р 51170-98
ГОСТ Р 51171-98
48
ГОСТ Р 51189-98
49
ГОСТ Р 51725.62002
50
ГОСТ Р 519042002
ГОСТ Р 522922004
ГОСТ Р 522942004
51
52
53
54
ГОСТ Р ИСО
10006-2005
ГОСТ Р ИСО
10303-1-99
55
ГОСТ Р ИСО
10303-11-2000
56
ГОСТ Р ИСО
10303-203-2003
57
ГОСТ Р ИСО
10303-21-2002
58
ГОСТ Р ИСО
10303-21-99
59
ГОСТ Р ИСО
10303-22-2002
60
ГОСТ Р ИСО
10303-31-2002
61
ГОСТ Р ИСО
10303-32-2002
62
ГОСТ Р ИСО
10303-34-2002
3
Обмен данными. Структура идентификации организаций
Качество программных средств. Термины и определения
Информационная технология. Комплекс стандартов на
автоматизированные системы. Термины и определения
Качество служебной информации. Термины и определения
Качество служебной информации.
Правила предъявления информационных технологий на сертификацию
Средства программные систем вооружения.
Порядок разработки
Каталогизация продукции для федеральных государственных нужд.
Сети телекоммуникационные и базы данных. Требования
информационной безопасности
Программное обеспечение встроенных систем.
Общие требования к разработке и документированию
Информационная технология. Электронный обмен информацией.
Термины и определения
Информационная технология. Управление организацией.
Электронный регламент административной и служебной деятельности.
Основные положения
Системы менеджмента качества. Руководство по менеджменту качества
при проектировании
Системы автоматизации производства и их интеграция.
Представление данных об изделии и обмен этими данными.
Часть 1. Общие представления и основополагающие принципы
Системы автоматизации производства и их интеграция.
Представление данных об изделии и обмен этими данными.
Часть 11. Методы описания. Справочное руководство по языку Express
Системы автоматизации производства и их интеграция.
Представление данных об изделии и обмен этим данными.
Часть 203. Прикладной протокол. Проекты с управляемой конфигурацией
Системы автоматизации производства и их интеграция.
Представление данных об изделии и обмен этими данными. Часть 21.
Методы реализации. Кодирование открытым текстом структуры обмена
Системы автоматизации производства и их интеграция.
Представление данных об изделии и обмен этими данными. Часть 21.
Методы реализации. Кодирование открытым текстом структуры обмена
Системы автоматизации производства и их интеграция. Представление
данных об изделии и обмен этими данными. Часть 22. Методы
реализации. Стандартный интерфейс доступа к данным
Системы автоматизации производства и их интеграция.
Представление данных об изделии и обмен этими данными. Часть 31.
Методология и основы аттестационного тестирования. Общие положения
Системы автоматизации производства и их интеграция.
Представление данных об изделии и обмен этими данными. Часть 32.
Методология и основы аттестационного тестирования.
Требования к испытательным лабораториям и клиентам
Системы автоматизации производства и их интеграция.
Представление данных об изделии и обмен этими данными. Часть 34.
Методология и основы аттестационного тестирования. Методы
абстрактного тестирования для реализации прикладных протоколов
119
Продолжение табл. 3.3
1
63
2
ГОСТ Р ИСО
10303-41-99
64
ГОСТ Р ИСО
10303-43-2002
65
ГОСТ Р ИСО
10303-44-2002
66
ГОСТ Р ИСО
10303-45-2000
67
ГОСТ Р ИСО
10303-46-2002
68
ГОСТ Р ИСО
10303-49-2003
ГОСТ Р ИСО
14040-99
ГОСТ Р ИСО
14041-2000
ГОСТ Р ИСО
14042-2001
ГОСТ Р ИСО
14043-2001
ГОСТ Р ИСО
15225-2003
ГОСТ Р ИСО
9000-2001
ГОСТ Р ИСО
9001-2001
ГОСТ
Р ИСО/МЭК
12207-99
ГОСТ
Р ИСО/МЭК
14764-2002
ГОСТ
Р ИСО/МЭК
15408-1-2002
ГОСТ
Р ИСО/МЭК
15910-2002
ГОСТ
Р ИСО/МЭК
2382-23-2004
ГОСТ
Р ИСО/МЭК
6937-93
69
70
71
72
73
74
75
76
77
78
79
80
81
120
3
Системы автоматизации производства и их интеграция. Представление
данных об изделии и обмен этими данными. Часть 41. Интегрированные
обобщенные ресурсы. Основы описания и поддержки изделий
Системы автоматизации производства и их интеграция. Представление
данных об изделии и обмен этими данными. Часть 43. Интегрированные
обобщенные ресурсы. Структура представлений.
Системы автоматизации производства и их интеграция. Представление
данных об изделии и обмен этими данными. Часть 44. Интегрированные
обобщенные ресурсы. Конфигурация структуры изделия.
Системы автоматизации производства и их интеграция. Представление
данных об изделии и обмен этими данными. Часть 45. Интегрированные
обобщенные ресурсы. Материалы
Системы автоматизации производства и их интеграция. Представление
данных об изделии и обмен этими данными. Часть 46. Интегрированные
обобщенные ресурсы. Визуальное представление.
Представление данных об изделии и обмен этими данными. Часть 49.
Интегрированные обобщенные ресурсы. Структура и свойства процесса
Управление окружающей средой. Оценка жизненного цикла.
Принципы и структура
Управление окружающей средой. Оценка жизненного цикла.
Определение цели, области исследования и инвентаризационный анализ
Управление окружающей средой. Оценка жизненного цикла.
Оценка воздействия жизненного цикла
Управление окружающей средой. Оценка жизненного цикла.
Интерпретация жизненного цикла
Номенклатура. Номенклатура данных по медицинским изделиям
для информационного обмена
Системы менеджмента качества. Основные положения и словарь
Системы менеджмента качества. Требования
Информационная технология.
Процессы жизненного цикла программных средств
Информационная технология. Сопровождение программных средств
Информационная технология. Методы и средства обеспечения
безопасности. Критерии оценки безопасности информационных
технологий. Часть 1. Введение и общая модель
Информационная технология.
Процесс создания документации пользователя программного средства
Информационная технология. Словарь. Часть 23. Обработка текста
Информационная технология. Набор кодированных графических знаков
для передачи текста. Латинский алфавит
Окончание табл. 3.3
1
82
90
91
92
93
2
ГОСТ
Р ИСО/МЭК
9075-93
ГОСТ
Р ИСО/МЭК
9126-93
ГОСТ
Р ИСО/МЭК
9594-1-98
ГОСТ
Р ИСО/МЭК
9595-99
ГОСТ
Р ИСО/МЭК
9646-1-93
ГОСТ
Р ИСО/МЭК ТО
15271-2002
ГОСТ
Р ИСО/МЭК ТО
16326-2002
ГОСТ Р
ИСО/ТО 1030312-2000
ОК 014-2000
ОК 015-94
ОК 025-2001
ОК 031-2002
94
Р 50.1.027-2001
95
Р 50.1.028-2001
96
Р 50.1.029-2001
97
Р 50.1.030-2001
98
Р 50.1.031-2001
99
Р 50.1.032-2001
100
101
РД 50-34.698-90
РД 50-605-86
83
84
85
86
87
88
89
3
Информационная технология. Язык баз данных SQL с расширением
целостности
Информационная технология. Оценка программной продукции.
Характеристики качества и руководства по их применению
Информационная технология. Взаимосвязь открытых систем.
Справочник. Часть 1. Общее описание принципов, моделей и услуг
Информационная технология. Взаимосвязь открытых систем.
Определение общих услуг информации административного управления
Информационная технология. Взаимосвязь открытых систем.
Методология и основы аттестационного тестирования.
Часть 1. Общие положения
Информационная технология. Руководство по применению ГОСТ
Р ИСО/МЭК 12207 (Процессы жизненного цикла программных средств)
Программная инженерия. Руководство по применению ГОСТ
Р ИСО/МЭК 12207 при управлении проектом
Системы автоматизации производства и их интеграция.
Представление данных об изделии и обмен этими данными.
Часть 12. Методы описания. Справочное руководство по языку Express-1
Общероссийский классификатор валют
Общероссийский классификатор единиц измерения
Общероссийский классификатор стран мира
Общероссийский классификатор видов грузов, упаковки
и упаковочных материалов.
Рекомендации по стандартизации. CALS-технологии.
Автоматизированный обмен технической информацией.
Основные положения и общие требования
Рекомендации по стандартизации. CALS-технологии.
Методология функционального моделирования.
Рекомендации по стандартизации. CALS-технологии.
Интерактивные электронные технические руководства.
Общие требования к содержанию, стилю и оформлению.
Рекомендации по стандартизации. CALS-технологии.
Интерактивные электронные технические руководства.
Требования к логической структуре базы данных.
Рекомендации по стандартизации. CALS-технологии.
Терминологический словарь.
Часть 1. Стадии жизненного цикла продукции
Рекомендации по стандартизации. CALS-технологии.
Терминологический словарь. Часть 2. Терминология, относящаяся
к применению серии стандартов ГОСТ Р ИСО 10303
Автоматизированные системы. Требования к содержанию документов
Методические указания по применению стандартов на статистический
приемочный контроль
121
В целом можно констатировать, что стандартизация занимает одно из ключевых мест в решении сложной комплексной межотраслевой проблемы внедрения
CALS-технологий в стране. Это предопределяет необходимость создания нормативного обеспечения на основе методов и средств функциональной стандартизации в данной области, гармонизированного с требованиями международных стандартов.
PC устанавливают термины и определения понятий в области CALSтехнологий. Термины, установленные в PC, обязательны для применения во всех
видах документации и литературы по технологиям непрерывной информационной
поддержки жизненного цикла продукции.
В настоящее время в России приняты и введены в действие рекомендации по
стандартизации Р50.1.027-2001 «Информационные технологии поддержки жизненного цикла изделия. Автоматизированный обмен технической информацией.
Основные положения и общие требования». Выполненные с учетом как MIL-STD1840C, так и действующих российских стандартов, эти РС распространяются
на обмен между организациями или системами конструкторскими, технологическими, программными и другими проектными данными, представленными в электронном виде. РС определяют основные правила формирования пакета технических данных для электронного обмена, форматы представления технических данных об изделии, а также устанавливают требования и соглашения, относящиеся
к логическому распознаванию файлов независимо от среды передачи технической
информации.
3.7. СОВМЕСТНОЕ ИСПОЛЬЗОВАНИЕ СТАНДАРТОВ
В технической цели CALS, так называемой модели изделия, определен ряд
стандартов CALS. Общая структура STEP включает архитектуру и представление
для структур изделия, определение, идентификацию и некоторые свойства изделия.
Каждый вид информации представляется через соответствующий стандарт,
например:
• Информация Логистики через LSA /LSAR (MIL-STD-138, АЕСМА и т. д.).
• Текстовая информация через SGML, HyTime и т. д.
• Информация об изображениях через CGM. ССТТТ. group 4 и т. д.
Различные наборы информации вместе компонуются в STEP через «программы обработки».
Ключевым понятием для CALS является концепция ИНТЕГРИРОВАННОЙ
БАЗЫ ДАННЫХ, которая содержит всю информацию, необходимую для строительства и обслуживания данной конструкции.
Эта концепция пришла от большинства основных подрядчиков к субподрядчикам систем и даже к индивидуальным поставщикам. Все данные, используемые
для создания отдельного элемента конструкции, материалы, процессы, комплектующие и т. д. будут накапливаться в интегрированной базе данных и будут доступны как заказчику, так и самому разработчику (рис. 3.22). Все вовлеченные
122
поставщики будут иметь свои собственные производственные базы данных, которые будут заполнять CALS-информацией окончательную интегрированную базу
данных.
Стандарты CALS покрывают спектр потребностей пользователей, обеспечивая единое представление текста, графики, информационных структур и данных
о проекте, сопровождении и производстве, включая звук, видео, мультимедийные
средства, передачу данных, хранение данных, документацию и многое другое,
для всех приложений.
Рис. 3.22. Примеры стандартов, включенных в модель изделия
3.8. КОНТРОЛЬНЫЕ ВОПРОСЫ
1. Деление стандартов на группы.
2. Назначение стандарта STEP.
3. Взаимосвязь основных разделов стандарта ИСО 10303 STEP.
4. Что такое спецификация NATO Product Data Model (NPDM)?
5. Взаимосвязь объектов, описывающих классификацию изделий.
6. Дать характеристику языка Express.
7. Основные зарубежные стандарты. Их назначение.
8. Охарактеризовать инициативу PLCS (Product Life Cycle Support).
9. Стандарты России и их связь с зарубежными стандартами.
10. Концепция интегрированной базы данных.
123
4. ИНФОРМАЦИОННАЯ ИНТЕГРАЦИЯ ПРОЦЕССОВ
ЖИЗНЕННОГО ЦИКЛА ИЗДЕЛИЯ
Технологии представления данных являются набором методов для представления в электронном виде данных об изделии, относящихся к отдельным процессам ЖЦ изделия. Эти технологии предназначены для автоматизации отдельных
процессов ЖЦ изделия, что является одним из пунктов стратегии CALS по созданию ЕИП. Технологии представления данных включают также технологии перевода данных из бумажного в электронный вид.
Рассматриваемая группа CALS-технологий состоит из более или менее известных методов (реализованных в соответствующих автоматизированных системах), которые можно расположить по трем группам (в соответствии с укрупненными этапами ЖЦ):
• проектирование изделия. В данную группу попадают технологии автоматизации проектирования изделия, в частности компьютерные системы автоматизированного проектирования (CAD), системы автоматизированной подготовки производства (САМ), системы инженерных расчетов (САЕ) и т. п.;
• производство изделия. В данную группу попадают технологии автоматизации производственных процессов и их планирования. Сюда относятся следующие
типы автоматизированных систем: MRP (Material Requirements Planning – планирование потребностей в материалах), MRP-II (Manufacturing Resource Planning –
планирование ресурсов производства), ERP (Enterprise Resource Planning – планирование ресурсов предприятия). Эти системы в отечественной терминологии чаще
всего называются АСУП (Автоматизированная система управления производством/предприятием);
• поставка и эксплуатация изделия. В данную группу попадают технологии
автоматизации процессов поставки и эксплуатации изделия, в частности:
– системы логистической поддержки изделия. К данной категории относятся
системы автоматизации обслуживания и ремонта изделия на этапе эксплуатации,
заказа комплектующих к изделию, поставки изделий и комплектующих, в частности SCM-системы;
– системы электронной коммерции. К данной категории относятся отдельные
блоки ERP-систем, а также самостоятельные системы, предназначенные для проведения коммерческих операций в электронном виде, в том числе CRM-системы.
Среди этих бурно развивающихся в настоящий момент систем можно выделить
системы типа В2В (business-to-business: взаимодействие поставщиков между собой) и системы типа В2С (business-to-customer: взаимодействие поставщика и покупателя);
Интерактивные электронные технические руководства (ИЭТР). К данной категории относятся автоматизированные системы, предоставляющие пользователю
эксплуатационную информацию по конкретному изделию, а также возможности
по диагностике изделия, поиску и устранению неисправностей, обучению, взаимодействию с поставщиком и т. п.
124
На основе перечня приведенных технологий и поддерживающих их автоматизированных систем может сложиться впечатление, что и в мире, и у нас в стране
CALS-технологии используются уже давно. Однако это не совсем верно, поскольку к CALS-технологиям представления данных предъявляется одно важное требование. Оно заключается в том, что данные технологии должны обеспечивать стандартизованный интерфейс к представляемым ими данным. Такой интерфейс необходим на окончательном этапе стратегии CALS для того, чтобы интегрировать
отдельные процессы ЖЦ в ЕИП.
Технологии интеграции данных – это набор методов для интеграции автоматизированных процессов ЖЦ и относящихся к ним данных, представленных
в электронном виде, в рамках ЕИП. Таким образом, эти технологии реализуют заключительный этап стратегии CALS по созданию ЕИП для всех участников ЖЦ
изделия. Исходной точкой для данной группы технологий является результат работы технологий представления данных, т. е. автоматизированные процессы и данные, представленные в электронном виде.
Технологии интеграции данных могут пониматься как технологии управления
интеллектуальным продуктом, т. к. они предназначены для управления всей информацией, созданной об изделии в ходе его ЖЦ. Среди CALS-технологий интеграции данных об изделии на стадии производства и эксплуатации ключевой является технология, основанная на системах управления данными об изделии и информационными процессами (Product Data Management – PDM).
PDM – категория программного обеспечения, позволяющая сохранять данные
об изделии в базах данных. К данным об изделии, прежде всего, относят инженерные данные, такие как CAD-модели и чертежи (см. CAD), цифровые макеты
(см. DMU), спецификации материалов (см. BOM). Метаданные содержат информацию о создателе файла и текущем статусе соответствующего компонента.
Система PDM позволяет организовать совместный доступ к этим данным,
обеспечивая их постоянную целостность, обеспечивает внесение необходимых изменений во все версии изделия, помогает модифицировать спецификацию материалов, конфигурировать варианты изделия. Однако самым важным преимуществом системы PDM является ее использование на протяжении всего жизненного
цикла изделия в рамках концепции управления этим циклом. Большинство PDMсистем позволяет одновременно работать с инженерными данными, полученными
от разных CAD-систем.
В основе PDM-систем лежат данные об изделии, которые являются совокупностью информационных объектов, порождаемых в процессе проектирования
и разработки изделия, содержащей сведения о составе изделия, о геометрических
моделях изделия, его компонентах и их технических характеристиках, об их отношениях в структуре изделия, о результатах расчетов и моделирования, о допусках
на изготовление деталей, технологии производства и т. д.
Основные задачи PDM-систем – это структурирование всей информации
об изделии, управление конструкторским документооборотом, ведение архива
конструкторской и технологической документации и, конечно, интеграция с CADсистемами и системами технологического проектирования. PDM-система на пред125
приятии является, по сути, центром интегрированной системы управления, связующим звеном между всеми системами в корпоративной среде предприятия. Использование PDM-систем позволяет решить не только проблемы, связанные с документооборотом предприятия. Одним из важнейших преимуществ использования
PDM-системы является возможность формирования на предприятии непротиворечивой базы нормативно-справочной информации и поддержки ее в актуальном состоянии.
Использование PDM также решает обозначенные выше задачи интеграции
различных CAD-систем и систем технологического проектирования между собой.
Большинство современных PDM-систем имеет интерфейсы к CAD-системам практически всех ведущих поставщиков (необходимо заметить, что именно наличие
интерфейсов к тем или иным CAD-системам во многом определяет стоимость решения на базе PDM).
С одной стороны, такие системы выступают в качестве хранилища всех данных об изделии и взаимодействуют с прикладными программами, создающими
или использующими данные об изделии. Данные, созданные любой прикладной
программой, передаются на хранение в PDM-систему и становятся, таким образом,
доступными любому участнику ЖЦ изделия, имеющему соответствующие права
доступа. При необходимости изменить или обработать данные об изделии прикладная система запрашивает и получает эти данные из PDM-системы.
С другой стороны, PDM-системы должны решать задачу повышения эффективности работы отдельного пользователя. В этом случае они должны выступать
в качестве рабочей среды пользователя, предоставляя ему нужные данные в нужное время в нужной форме.
В течение ЖЦ изделия PDM-системе приходится взаимодействовать с сотнями прикладных систем, причем почти каждая из них имеет свой собственный формат представления данных. Для решения проблемы взаимодействия с прикладными системами необходимо применять стандартизованные интерфейсы взаимодействия, включающие форматы представления данных об изделии, используемые
для передачи данных, а также процедуры взаимодействия PDM-системы и прикладных систем. Именно этим и обусловлено требование наличия стандартизованного интерфейса у технологий представления данных, т. е. прикладных систем.
Таким образом, технологии интеграции данных обеспечивают создание ЕИП,
включающего хранилище данных на основе PDM-системы, и прикладных пакетов.
При этом данные компоненты интегрированы между собой посредством стандартизованных интерфейсов взаимодействия. Основными функциями PDM-системы
являются:
• управление составом изделия;
• управление документами;
• управление конфигурацией, т. е. ведение версий проекта;
• управление изменениями;
• управление потоками работ;
• управление доступом;
• управление проектами;
126
• хранение проектных данных и доступ к ним, в том числе ведение распределенных архивов документов, их поиск, редактирование, маршрутизация, создание
спецификаций;
• структурирование и визуализация данных;
• защита информации;
• интеграция данных (поддержка типовых форматов, конвертирование данных).
Целями любой PDM-системы являются:
• обеспечение полноты информации об изделии;
• обеспечение целостности данных;
• обеспечение достоверности данных;
• разграничение доступа к данным;
• обмен актуальными данными со всеми участниками ЖЦИ.
Применение PDM-технологии дает следующие преимущества:
• улучшение эффективности разработок и уменьшение их стоимости;
• сокращение сроков вывода новых конкурентоспособных изделий на рынок;
мсокращение доли брака и уменьшение затрат, связанных с внесением изменений;
• автоматизация процедуры прохождения документов от задания на их разработку до передачи данных в производство;
• устранение избыточности данных и обеспечение быстрого поиска.
PDM-технология предназначена для управления всеми данными об изделии
и информационными процессами ЖЦ изделия, и она объединяет различные системы между собой так, как это представлено на рис. 4.1.
Рис. 4.1. Информационная интеграция процессов ЖЦ изделия
127
Данные об изделии представляют собой всю информацию о продукте в течение его ЖЦ в электронном виде. Они включают в себя: состав и структуру изделия, геометрические данные, чертежи, планы проектирования и производства, спецификации, нормативные документы, программы для станков с ЧПУ, результаты
анализа, корреспонденцию, сведения о партиях и отдельных экземплярах изделия
и многое другое.
4.1. СИСТЕМА УПРАВЛЕНИЯ ДАННЫМИ ОБ ИЗДЕЛИИ PDM
Информационные процессы являются процессами ЖЦ изделия, создающими
или использующими данные о нем. Примером служит формальная процедура изменения изделия. Совокупность информационных процессов представляет собой
документооборот, происходящий в течение ЖЦ изделия. Естественно, документооборот, управляемый PDM-системой, называется электронным документооборотом.
При решении глобальной задачи CALS-технологий – повышения эффективности управления информацией об изделии – роль PDM-технологии состоит в том,
чтобы сделать информационные процессы максимально прозрачными и управляемыми. Основным методом, применяемым для этого, является повышение доступности данных для всех участников ЖЦ изделия, что требует интеграции данных
об изделии в логически единую информационную модель.
Наиболее распространенные задачи, решаемые с помощью PDM-технологии:
• создание ИИС для всех подразделений предприятия;
• автоматизация управления конфигурацией изделия;
• построение системы качества продукции на предприятии согласно международным стандартам серии ISO 9000;
• создание электронного архива чертежей и прочей технической документации (наиболее простой способ применения PDM-технологии).
Для реализации PDM-технологии существуют специализированные программные средства, называемые PDM-системами (системами управления данными об изделии). Управление данными об изделии (УДИ) схематически представлено на рис. 4.2.
УДИ представляет собой компьютерные средства управления всеми связанными с изделием данными и информационными процессами ЖЦ. Как показано
на схеме, система УДИ имеет информационные связи с САПР, АСУП, УПр, УКф,
УКч и другими автоматизированными системами, что и свидетельствует о системообразующем характере и роли этой системы. В отличие от АСУП, контролирующей информацию о ресурсах предприятия, PDM-системы направлены именно
на управление информацией о продукте.
Интерфейс с пользователем поддерживается визуализацией данных проекта
одновременно в нескольких окнах. Для визуализации данных разных аспектов
в PDM имеется ряд браузеров. Типичные изображения структуры изделия, создаваемые браузерами, представляются иерархическим списком или графически в виде дерева изделия или его фрагментов. В других окнах могут быть помещены
различные виды, такие как 2D чертеж или 3D изображение; описания моделей;
128
принципиальные схемы; атрибуты объекта (исполнитель, номер версии, дата утверждения и т. п.). Иногда для визуализации и редактирования данных в PDM конкретной фирмы привлекаются браузеры и редакторы других изготовителей.
Рис. 4.2. Управление данными об изделии (УДИ = PDM)
Для примера на рис. 4.3 показан небольшой фрагмент дерева изделия. Обычно
на экране дисплея рядом с названием компонента структуры высвечивается также
присвоенный ему код. Выбор любого компонента (узла дерева) позволяет, вопервых, получить в появляющихся окнах требуемую информацию о компоненте;
во-вторых, для компонента, являющегося сборкой, раскрыть следующий по иерархии
фрагмент, в котором данный компонент будет представлен уже корневым узлом.
Рис. 4.3. Фрагмент дерева изделия
129
Целостность данных поддерживается в процессе управления конфигурацией
проекта, а также тем, что нельзя одновременно изменять один и тот же объект разным разработчикам, каждый из них должен работать со своей рабочей версией.
Другими словами, необходимо обеспечение синхронизации изменения данных,
разделяемых многими пользователями.
Для этого выполняется авторизация пользователей и разрабатываются средства ведения многих версий проекта. Во-первых, пользователи подразделяются
на классы (администрация системы, руководство проектом и частями проекта,
группы исполнителей-проектировщиков) и для каждого класса вводят определенные ограничения, связанные с доступом к разделяемым данным; во-вторых, доступ
регламентируется по типам разделяемых данных. Данным могут присваиваться
различные значения статуса, например «правильно», «необходимо перевычисление», «утверждено в качестве окончательного решения» и т. п. Собственно синхронизация выполняется с помощью механизмов типа рандеву или семафоров,
рассматриваемых в пособиях по параллельным вычислениям.
В системе BaanPDM каждому пользователю в зависимости от его роли назначается уровень прав доступа – один из восьми возможных. На низшем уровне
пользователь может только просматривать данные. На высшем уровне, присваиваемом старшему администратору, допускаются любые модификации данных любого проекта и архивов. В функции лица, являющегося системным администратором, входят упорядочение данных с их распределением по дискам, контроль
за правами доступа пользователей, связь с внешними системами (управление импортом-экспортом данных) и др.
Типичная схема разделения рабочего пространства между параллельно работающими пользователями показана на рис. 4.4.
Рис. 4.4. Информационные связи разработчиков с зонами базы данных
Следующей важной функцией PDM является управление документами и документооборотом. Проектная документация характеризуется разноплановостью
и большими объемами. В процессе проектирования используют чертежи, конструкторские спецификации или ВОМ, пояснительные записки, ведомости применяемости изделий, различного рода отчеты и др. Кроме того, в интегрированных
130
автоматизированных системах проектирования и управления в документооборот
входит большое число документов, связанных с процедурами маркетинга, снабжения, планирования, администрирования и т. п.
Важно обеспечить автоматический учет влияния и распространения вносимых
в проект изменений на другие части проектной документации.
Для подготовки, хранения и сопровождения необходимых документов, в том
числе чертежей и схем, в PDM включают специализированные системы управления документами и системы управления документооборотом или адаптируют полнофункциональные системы делопроизводства, разработанные независимо от конкретных PDM. Часто используют программы Lotus Notes и Lotus Domino компании
Lotus Development. Возможности управления чертежно-конструкторской документацией, подготовленной в AutoCAD и Microstation, имеются в продуктах DOCS
Open (компания Hummingbird), CADLink, входящем в систему управления документами и бизнес-процессами Documentum, Search (белорусская компания Интермех) и ряде других.
В системе Search осуществляется хранение и поиск данных, доступ к ним, документооборот, разработка спецификаций, внесение изменений и др. Для этого
имеется редактор извещений об изменениях в проекте, средства обеспечения групповой работы над проектом, модуль доступа к документам, расположенным
на других узлах сети. Редактирование и просмотр выполняются с помощью внешних редакторов.
Следует отметить, что параллельное проектирование, интеграция автоматизированных систем проектирования и управления на современных предприятиях
возможны только в распределенной среде. Распределенные хранение и обработка
информации в большинстве случаев осуществляются на базе применения технологий SOAP, CORBA или DCOM, языков Java и XML. Данные проекта при этом находятся в хранилищах данных, т. е. в нескольких базах распределенного банка
данных. Находят применение трехзвенные распределенные системы с уровнями
сервер баз данных–сервер приложений–клиенты. Принимаются меры по защите
информации, типичные для корпоративных информационных систем. Разработаны
рекомендации по внедрению операций с электронными цифровыми подписями.
Интеграция данных на ранних этапах развития PDM связывалась только с организацией сквозного проектирования изделий в рамках конкретной САПР. В настоящее время в связи с развитием CALS-технологий основным содержанием проблемы интеграции стало обеспечение интерфейса САПР с другими автоматизированными системами. Проблема решается с помощью поддержки типовых
форматов, например путем конвертирования данных из общепринятых форматов
во внутренние представления конкретных САПР.
В CALS-технологиях взаимодействие систем основано на стандартах STEP,
поэтому в ряде PDM имеются конверторы из предложенного в STEP языка Express.
В STEP введен прикладной протокол AP208, представляющий собой
информационную модель, относящуюся к управлению процессами изменений
в жизненном цикле изделий. В соответствии с AP208 внесению изменений пред131
шествует идентификация фактов (недостатков), требующих внесения изменений,
установление вызвавших их причин и определение лиц, вносящих изменения. Среди других форматов данных обычно используются IGES, DXF, VRML, SAL, EDIF,
текстовые и 2D графические форматы и др.
Адаптация САПР к условиям конкретных предприятий может быть осуществлена с помощью языков расширения. Язык расширения – язык программирования,
позволяющий адаптировать и настраивать системную среду на выполнение новых
проектов. Язык расширения должен обеспечивать доступ к различным компонентам системной среды, объединять возможности базового языка программирования
и командного языка, включать средства процедурного программирования.
Для большинства языков расширения базовыми являются Lisp или C.
Примерами таких языков могут служить языки Skill из Design Framework-2
фирмы Cadence или CCL (CASE Comment Language) фирмы Matra Datavision, являющиеся Lisp-подобными, или язык AMPLE из PDM Falcon Framework фирмы
Mentor Graphics, базирующийся на языках C и ПАСКАЛЬ.
Для того чтобы PDM-система стала давать ощутимую отдачу, необходимо
разработать продуманную стратегию внедрения этой системы и четко следовать
ей. Большинство организаций, успешно использующих PDM-системы, прошли через одни и те же процедуры, которые приводятся ниже в виде последовательности
шагов, которые на самом деле могут пересекаться и повторяться много раз
(рис. 4.5).
Рис. 4.5. Этапы внедрения CALS-технологий на предприятии
132
Программа работ по созданию ЕИП предприятия должна включать в себя
следующие этапы:
• Анализ существующего состояния бизнес-процессов. Цель анализа – выявить существующее взаимодействие между бизнес-процессами информационного
обеспечения и оценить их рациональность и эффективность. Для этой цели с использованием CASE-технологий (CASE – Computer Aided System Engineering) разрабатываются модели, содержащие детальное описание выполняющихся процессов в их взаимосвязи.
• Формирование концепции информационной интеграции и внедрения СALSтехнологий на предприятии. Формирование концепции включает выбор показателей оценки эффективности процессов, формирование целей внедрения CALSтехнологий и стратегии их достижения. Основными показателями являются: конкурентоспособность (или качество) продукции, затраты и длительность процессов
разработки и освоения производства изделия.
• Выбор PDM-системы и ее адаптация к существующим и новым программным средствам. Системы управления данными об изделии в настоящее время достаточно широко реализованы и представлены на российском рынке. Поэтому перед каждым предприятием будет стоять задача, какую систему выбрать и как ее
применять для решения конкретных задач. Задача выбора и приобретения технических средств (компьютеров и сетевого оборудования) тесно связана с задачей
выбора PDM-системы.
• Разработка стандартов предприятия. Разработка комплекса нормативной документации, регламентирующей порядок создания и изменения информации
об изделии в PDM-систему, на основе международных, государственных и отраслевых стандартов необходима для организационного обеспечения внедрения PDMсистемы.
• Наполнение БД PDM информацией. Основной компонент систем PDM –
банк данных (БнД). Он состоит из системы управления базами данных и баз данных (БД). Межпрограммный интерфейс в значительной мере реализуется через
информационный обмен с помощью банка данных. PDM отличает легкость доступа к иерархически организованным данным, обслуживание запросов, выдача ответов не только в текстовой, но и в графической форме, привязанной к конструкции
изделия. Поскольку взаимодействие внутри группы проектировщиков в основном
осуществляется через обмен данными, то в системе PDM часто совмещают функции управления данными и управления параллельным проектированием.
Информация, заносимая в БД PDM, включает две категории данных. Вопервых, необходимо адаптировать PDM-систему к специфике предприятия, т. е.
ввести в нее все используемые классификаторы, а также модель потока работ
на предприятии. Кроме того, для эффективного использования накопленного производственным предприятием опыта требуются значительные затраты на перевод
существующей документации о разработанных изделиях в стандартное представление и занесение ее в хранилище данных интегрированной информационной системы.
133
PDM-система также является и системой управления проектом, т. к. фактически предназначена для работы над проектом по разработке, производству и продвижению на рынок наукоемкого промышленного изделия. PDM-система одновременно является рабочей средой пользователя и средством интеграции данных
на протяжении всего ЖЦ изделия.
Главной задачей PDM-системы как рабочей среды пользователя является предоставление соответствующему сотруднику нужной ему информации в нужное
время в удобной форме (в соответствии с правами доступа). Пользователями PDMсистемы выступают все сотрудники предприятий-участников ЖЦ изделия (конструкторы, технологи, работники технического архива), а также служащие, работающие в других предметных областях: сбыт, маркетинг, снабжение, финансы,
сервис, эксплуатация и т. п. PDM-система обеспечивает все потребности пользователя, начиная от просмотра спецификации узла и кончая изменением твердотельной модели детали или утверждением измененной детали начальником.
При необходимости PDM-система пользуется помощью других систем
для обработки данных (например, САПР), самостоятельно определяя, какое именно внешнее приложение необходимо запустить для обработки той или иной информации. Среди перечня функций, указанных выше, можно выделить следующие:
1. Управление хранением данных и документов. Все данные и документы
PDM-системе хранятся в специальной подсистеме (хранилище данных), которая
обеспечивает их целостность, организует доступ к ним в соответствии с правами
доступа и позволяет осуществлять их поиск. Данные документы являются электронными, т. е. обладают электронной подписью. Управление документами включает в себя:
• версии документов;
• структурируемые документы;
• изменения документов;
• статусы документов;
• ассоциацию документов с любыми объектами;
• протоколирование работы с документами.
2. Управление процессами. PDM-система отслеживает все операции пользователей с данными, в том числе следит за версиями. Кроме того, PDM-система
управляет потоком работ (например, в процессе проектирования изделия) и занимается протоколированием действий пользователей и изменений данных.
3. Управление составом изделия. PDM-система содержит информацию о составе изделия, его вариантах. Важной особенностью является наличие нескольких
представлений состава изделия для различных предметных областей (конструкторский состав, технологический состав, маркетинговый состав и т. д.).
4. Классификация. PDM-система позволяет производить распределение изделий и документов в соответствии с различными классификаторами. Это может
быть использовано при поиске продукта с нужными характеристиками с целью его
повторного использования или для автоматизации присваивания обозначений
компонентам изделия.
134
На рис. 4.6 приведен пример вариантов состава изделия. Типичным примером
является конструкторская и технологическая спецификации изделия: конструкторы работают с «конструкторским» составом изделия, технологи же оперируют
«технологическим», который формируется при проектировании технологии сборки
по принципу «как должно собираться». Обычно технологический состав изделия
отличается от конструкторского, как минимум, наличием промежуточных подсборок, транспортной тары, расходных материалов и т. д. Другим примером вариантов
состава является разбиение сложного изделия по зонам и функциональному признаку (по системам).
а
б
Рис. 4.6. Пример вариантов состава изделия: а – конструкторский состав изделия (одноуровневая
сборка); б – технологический состав изделия (несколько подуровней сборки и дополнительные
материалы)
Системы управления данными об изделии ориентированы на большие системы управления базами данных и используются не только на этапе эксплуатации,
а в большей степени на этапе проектирования изделий.
При организации совместной работы различных служб предприятия, использующих различные системы автоматизации, встает вопрос об их информационной
совместимости. Для его решения PDM-система поддерживает нейтральную модель
данных, пригодную для представления самых различных данных об изделии.
Используя методологию стандарта STEP и требования к функциональности
PDM-системы, разработали программный комплекс «PDM STEP Suite» (PSS),
среди достоинств которого можно выделить:
135
• объектно-ориентированный подход, обеспечивающий гибкость системы;
• открытую информационную модель. Структура БД при необходимости может быть дополнена различными информационными объектами в соответствии
с требованиями конкретного предприятия;
• соответствие международным CALS-стандартам, которое необходимо
не только для построения ядра интегрированной информационной среды (ИИС)
предприятия, но и для успешного взаимодействия с иностранными партнерами;
• изначальную ориентацию системы на решение задач в масштабе предприятия, а не рабочей группы;
• трехуровневую сетевую архитектуру, в которой клиентский модуль взаимодействует с сервером БД через сервер приложений. Такая архитектура обеспечивает эффективное распределение вычислительной нагрузки при одновременной работе большого числа пользователей и низкие требования к программноаппаратному оснащению клиентских мест.
Основные функции PSS:
• взаимодействие с другими автоматизированными системами;
• управление различными нормативно-справочными разделами, классификаторами и ограничительными перечнями объектов;
• управление версиями изделий;
• управление конфигурацией изделия;
• управление различными точками зрения на состав изделия;
• управление характеристиками объектов;
• хранение различных документов (комплектов документов);
• управление изменениями;
• регистрация статусов (подписей) объектов с использованием ЭЦП;
• ведение организационной структуры и управление ролями сотрудников;
• управление технологическими данными;
• наличие встроенной системы управления потоками работ (WorkFlow
Management);
• управление описанием экземпляров и партий изделий;
• поиск объектов по различным критериям;
• управление разграничением доступа к объектам;
• генерация разнообразных отчетов.
Для удобства работы в ИИС специалистов различных направлений PSS позволяет использовать различные справочники:
• государственные, международные и внутренние стандарты и прочие нормативные документы;
• материалы (с учетом сортаментов);
• нормализованные детали (нормали);
• стандартные изделия;
• покупные комплектующие изделия;
• долговременные разделы БД, аккумулирующие собственный опыт предприятия;
• ранее выполненные (готовые) проекты;
• унифицированные узлы и детали;
136
• технологическое оборудование и оснастка (или парк оборудования);
• организационная структура предприятия и роли сотрудников;
• различные ограничительные перечни;
• перечни используемых характеристик, единиц измерения и других типов
служебной информации.
PSS позволяет создавать неограниченное количество систем классификаций
объектов и нормативно-справочных разделов в соответствии с любыми стандартами. Система PSS позволяет назначать индивидуальный доступ к любым разделам
справочников. Справочники могут иметь как древовидную, так и сетевую структуру.
Необходимо отметить, что каждый объект в системе PSS описывается единожды и никогда не дублируется. Для доступа к объекту используются ссылки, что
обеспечивает однозначность данных и сквозное проведение изменений. Так, один
объект-изделие может одновременно входить в состав нескольких сборочных единиц. Система PSS может настраиваться на специфику конкретного предприятия
посредством специального модуля и не требует дополнительного программирования.
Одним из основных информационных объектов в PSS является «изделие».
Этот объект описывает в БД материальный предмет, вещество, услугу, программный продукт, систему, состоящую из материальных предметов и программных
средств, взаимодействующих между собой. При помощи объекта «версия изделия»
описываются различные модификации и исполнения изделия. С изделием ассоциируется различного рода информация (которая накапливается на протяжении
всего ЖЦИ):
Набор характеристик. Для описания разнообразных свойств изделий в PSS
используется объект «характеристика». Перечень возможных характеристик может
легко дополняться. Важным атрибутом характеристики является «тип», с помощью
которого одна и та же характеристика может присоединяться к изделию на разных
стадиях ЖЦ. Например, при получении технического задания на разработку к изделию может быть присоединена характеристика «ресурс» с типом «требуемая»,
при выполнении проверочного расчета – с типом «расчетная», а после испытаний
опытного образца – с типом «измеренная». Характеристики, представляющие тайну, могут быть доступны только конкретным сотрудникам (для этого используется
функция разграничения доступа). Для легитимности характеристик им могут назначаться статусы с использованием ЭЦП.
Документы (комплекты документов). Система PSS позволяет хранить различные типы электронных документов. При этом документ может существовать самостоятельно или быть ассоциирован с любым объектом БД. Логически документ
(электронный технический документ) состоит из двух частей: содержательной
и реквизитной. В качестве содержательной части может выступать любой файл,
способный храниться в компьютере: 3D-модель, файл мультимедиа, растровое
изображение (например, отсканированный чертеж). Реквизитная часть содержит
аутентификационные и идентификационные данные документа, в том числе одну
или несколько ЭЦП. Документ имеет дерево версий, среди которых одна является
актуальной (активной). Встроенный механизм управления изменениями позволяет
проследить всю историю изменений каждого документа для последующего анали137
за и дает возможность произвести «откат» (возврат к предыдущим версиям). Вся
информация, порождаемая при инициировании и проведении изменений (служебные записки, документы, описывающие требуемые изменения (функции «красного
карандаша»), извещения об изменениях и др.), может храниться для последующего
использования.
Объекты-статусы. Под статусами в PSS подразумеваются результаты согласований и утверждений всех объектов системы.
Изделия-аналоги (заменяющие изделия). Для каждого изделия задается перечень изделий, заменяющих его. Такая связь является направленной. Например,
болт без покрытия можно заменить на никелированный болт, но никелированный
болт заменить на болт без покрытия нельзя.
Описание экземпляров и партий изделия. Важным этапом ЖЦ изделия является изготовление. Поскольку отклонения от технологии изготовления могут привести к серьезным последствиям в дальнейшей эксплуатации и ремонте, PSS позволяет вести учет специфики изготовления и последующего ремонта конкретного
экземпляра изделия (например, результаты испытаний конкретного образца).
Классификационная информация. Для упорядочивания информации в PSS используются справочники и классификаторы (см. выше). Часто по каким-либо причинам (например, для подбора другого резца) возникает необходимость просмотра
справочников и классификаторов, в которые входит изделие. Система PSS позволяет путем использования одной команды просмотреть все разделы справочников,
в которые входит изделие.
Непременным атрибутом PDM-системы является удобная и простая функция
поиска. Встроенный в PSS механизм поиска позволяет пользователю создавать
специфические запросы по произвольному набору критериев. Например, запрос
вида – «Найти все документы типа "чертеж", утвержденные сотрудником Ивановым в определенный промежуток времени». Соответственно, любой объект БД
может быть доступен посредством функции поиска (конечно, с учетом прав доступа к объекту).
4.2. ИНТЕГРАЦИЯ ДАННЫХ
Еще одной важной функцией PDM-системы является интеграция данных напротяжении всего производственного цикла, т. е. ИИС (рис. 4.7).
Вертикальная интеграция затрагивает PDM и прикладные системы. Ее суть
состоит в том, что данные об изделии, созданные прикладными системами, передаются на хранение в PDM-систему, а при необходимости их обработки или изменения – обратно, после чего вновь должны быть возвращены в PDM. При этом она
контролирует целостность, полноту и актуальность данных.
Примером данных, передаваемых из PDM-системы в АСУП, может служить
состав изделия. Важный компонент «бесшовной» интеграции на предприятии –
поддержка PDM-системой произвольного набора характеристик объектов, что позволяет интегрировать эту систему практически с любой другой компьютерной
системой. При этом вторая получает именно те данные, которые нужны ей
138
для выполнения своих функций. Например, данные о необходимом для производства детали количества материала или типе станков создаются на этапе проектирования детали и могут быть представлены в виде некоторого набора характеристик,
а тот, будучи переданным в АСУП, автоматически используется при закупке сырья
или планировании.
Можно выделить несколько уровней интеграции PDM-системы и других компьютерных приложений, используемых на предприятии.
Наиболее современным уровнем считается применение единой модели данных. Это означает, что все компьютерные системы (PDM, АСУП и прикладные)
работают с единой совместно используемой базой данных. Такой способ наиболее
близок к идеальному, но реализация его на практике практически отсутствует.
Рис. 4.7. Интеграция данных об изделии
Горизонтальная интеграция объединяет PDM-системы и АСУП. Ее задача –
создание и поддержание полной информационной модели предприятия, включающей данные как о его продукте, так и о ресурсах. Одним из основных преимуществ
такой модели является исключение повторного ввода данных при переходе изделия с этапа разработки (контролируется в основном PDM-системой) на этап производства (контролируется АСУП).
Следующим уровнем интеграции является прямой доступ к БД. При этом все
компьютерные системы имеют свои БД, но каждая из них беспрепятственно читает
и пишет данные в БД другой системы (например, PDM-система имеет неограниченный доступ к БД АСУП, и наоборот). Этот способ интеграции встречается
на практике, и многие PDM-системы владеют механизмами его реализации. Например, пакет TFlex Docs фирмы Топ Системы имеет возможность прямого доступа к внешним БД и возможность синхронизировать свою БД с ними в режиме реального времени.
Самый распространенный уровень интеграции – взаимодействие путем использования прикладных программных интерфейсов (API). Практически любая
полноценная PDM-система имеет свой API, с помощью которого пользователи могут настраивать ее в соответствии с потребностями своего предприятия. Таким образом, PDM-систему «учат общаться» с другими компьютерными системами. Это
можно сделать, разработав на предприятии небольшое приложение (шлюз), которое будет передавать данные из PDM-системы в АСУП, получая их с помощью
API PDM-системы и загружая в АСУП, используя API АСУП.
139
Наконец, самым простым уровнем интеграции приложений считаются файлы
обмена данными между ними. При осуществлении передачи данных от одной системы к другой первая будет генерировать файл, содержащий передаваемые данные, а вторая – читать его и получать эти данные. Для создания обменного файла
и для его чтения потребуются специальные программы – конверторы, которые будут преобразовывать данные из формата прикладной системы в формат обменного
файла и наоборот. При выборе формата обменного файла существуют различные
варианты. Можно использовать стандартные форматы, например формат, оговоренный в международном стандарте для обмена данными об изделии ИСО 10303
STEP. Можно разработать на предприятии (или внутри кооперации) свой собственный формат обменного файла.
Ведущие поставщики ERP-систем в последнее время уделяют все большее
внимание вопросам интеграции с PDM, т. к. только такая интеграция может обеспечить ERP-систему актуальной нормативной информацией для планирования
и существенно сократить избыточность данных и затраты времени на передачу
изделий из разработки в производство.
Для решения задачи интеграции ERP и PDM организацией ISO в середине
90-х гг. был разработан набор стандартов ISO 10303 STEP. Однако несмотря на все
усилия, ISO-стандарт, по целому ряду причин, не получил широкого распространения, и сегодня на рынке не так много систем, поддерживающих интеграцию
с его помощью.
На Западе предпринимаются попытки использовать для интеграции становящиеся все более популярными в последнее время специализированные системы
класса EAI – Enterprise Application Integration. Примерами таких систем могут служить Microsoft BizTalk или BEA WebLogic. Однако такие решения достаточно
сложны и дороги и пока не получили широкого распространения. В основном интеграция выполняется двумя путями – либо с помощью API, либо с помощью файлов экспорта/импорта данных.
Использование API более технологично и позволяет добиться более тесной
интеграции систем, однако имеет ряд ограничений. Прежде всего, существует
сильная привязка разработанного интерфейса к конкретным версиям продуктов,
которые интегрируются между собой. Даже незначительные изменения в структуре данных одного из интегрируемых продуктов могут потребовать переработки
интерфейсов. Кроме того, для разработки интерфейсов необходимы достаточно
серьезные знания в программировании.
Использование файлов экспорта/импорта для интеграции хотя и менее технологично, тем не менее в ряде случаев обеспечивает более гибкий подход и не требует столь глубоких знаний в программировании, как при использовании API. Наверное, поэтому большинство проектов по интеграции выполняется именно таким
способом.
Для иллюстрации подобного подхода к интеграции рассмотрим модуль интеграции ERP- и PDM-систем. В качестве PDM-системы была выбрана система
PartyPLUS. В качестве ERP-системы можно указать Microsoft Business SolutionsAxapta. Для интеграции двух систем необходимо разработать специальный модуль
140
интеграции, который обеспечивал бы передачу нормативно-справочной информации из PDM-системы PartyPlus в ERP-систему. Передача данных осуществляется
с помощью файлов импорта/экспорта.
Набор данных, которыми оперирует система PartyPLUS, существенно больше,
чем тот, который необходим ERP-системе для реализации функций планирования
и управления производством. ERP-системе нужны только состав изделия, нормы
расхода материалов, состав технологических маршрутов с перечнем операций
и рабочих центров и времена их выполнения. Все остальные данные, такие как
различные атрибуты изделий, узлов и деталей, версии документов и прочее, с чем
работает PDM, являются для нее излишними. Поэтому разработанный модуль интеграции осуществляет не только выгрузку данных из одной системы и загрузку их
в другую, но и их преобразование в необходимые форматы.
Схема работы модуля выглядит следующим образом. Из PDM-системы
PartyPLUS извлекаются необходимые данные (номенклатурные единицы, версии
спецификаций, состав спецификаций, технологические операции, рабочие центры,
версии маршрутов, маршруты), которые с помощью модуля интеграции преобразуются в формат файлов экспорта, затем файлы экспорта преобразуются в формат,
понимаемый ERP-системой Axapta, при этом происходит удаление излишней информации, и затем импортируются в ERP-систему.
Из ERP-системы в PDM передаются для синхронизации данных справочники
материалов, оборудования, единиц измерения, при этом механизм работы модуля
интеграции аналогичен описанному выше.
Кроме передачи нормативных данных о новых изделиях модуль интеграцию
отвечает за реализацию еще одной задачи – обработку извещений. Как только конструктор или технолог регистрирует в PDM-систем извещение об изменении состава изделия, изменении технологического маршрута и т. д., они немедленно передаются в ERP-систему в виде новых версий спецификаций и технологических
маршрутов. Реализация этого механизма стала возможна во многом благодаря
мощным функциям управления версиями спецификаций и маршрутов, реализованным в системе Axapta.
Использование модуля интеграции позволяет создать на предприятии единую
информационную среду, обеспечивающую реализацию концепции CALS, т. е. дает
предприятию возможность управлять замкнутым производственным циклом,
включающим в себя подготовку производства, его планирование и оперативное
управление.
В основе PLM лежит модель PDM, разрабатываемая и используемая, как правило, инженерными службами. На рис. 4.8 показано взаимодействие с моделью
основных потребителей информации.
По некоторым оценкам, на внедрение PLM-систем в 2003 г. было затрачено
более $2,3 млрд. Основной риск внедрения на первом этапе взяли на себя гиганты
автомобилестроительной и аэрокосмической отрасли. Во многих работах, посвященных этому вопросу, основное внимание уделяется программному обеспечению
PLM, в основе которого лежат такие PDM-системы, как TeamCenter (UGS PLM
141
Solutions), ENOVIA, SMARTEAM (Dassault Systemes), mySAP PLM (SAP) и многие
другие. В то же время, по нашему мнению, основная проблема внедрения PLM лежит в организационной сфере.
Рис. 4.8. Взаимодействие с моделью PLM основных потребителей информации
Успешное внедрение PLM во многом зависит от правильности организации
и эффективности функционирования создаваемого единого информационного пространства, на базе которого будет обеспечиваться информационная поддержка
жизненного цикла изделий.
Технологии PLM предполагают на каждом из этапов жизненного цикла интеграцию множества программных продуктов (офисные приложения, системы
CAD/CAM/CAE, системы управления базами данных, различные бизнесприложения). Многие из перечисленных продуктов, имеющих ту же функциональность, успешно функционировали до внедрения PLM-технологий. В них накоплена
большая информационная база (проекты в различных CAD-системах, разнообразные базы данных и т. д.). Одной из самых сложных проблем внедрения PLMтехнологий является перенос этой наработанной информационной базы в формируемое единое информационное пространство.
Для каждой отдельной задачи PLM выдвигаются свои уникальные требования. Причем в пределах одной задачи они уникальны для отделов предприятий
концерна. К примеру, перечислим требования к PLM для выполнения задачи конструкторского проектирования:
1. Работа с большим количеством компонентов и связей. Например, в современных больших электрических машинах содержится более 1 млн компонентов.
2. Интеграция сотен пользователей в единую среду разработки.
3. Согласование проекта с другими предприятиями концерна (в частности,
с проектировщиками и изготовителями турбин).
4. Интеграция с CAD/CAM/CAE- и ERP-системами.
5. Управление различными видами состава изделия (конструкторский, технологический, эксплуатационный и т. д.).
142
6. Синхронизация данных об изделии на протяжении жизненного цикла с проектными данными.
Понятно, что для других задач PLM некоторые из перечисленных выше пунктов будут другими, либо будут добавлены еще дополнительные требования.
Работа по каждому из пунктов представляет собой достаточно серьезную
проблему, решение которой включает в себя реструктуризацию и реорганизацию
существующих бизнес-процессов, построение программно-технической системы,
финансирование, обучение, внедрение ПО, поддержку, мотивацию персонала. Быстрое решение этих задач вряд ли возможно, скорее всего, это должен быть поэтапный, эволюционный путь развития.
В завершение хотелось бы отметить, что PLM – это не продукт, а стратегия
развития информационных технологий, направленная, с одной стороны, на объединение, а с другой – на распределение информации об изделии между участниками бизнес-процесса информационной поддержки изделия.
Использование PDM-системы ведет к уменьшению времени проектирования
на 20–30 %. За счет чего возможен такой рост? Сокращение сроков выхода изделия
на рынок связано, в первую очередь, с повышением эффективности процесса проектирования, вызванного применением PDM-системы. Оно имеет четыре аспекта:
1. PDM-система избавляет конструктора от непроизводительных затрат времени, связанных исключительно с поиском, копированием и архивированием данных, что при работе с бумажными носителями составляет 25–30 % его времени.
2. PDM-система позволяет улучшить коммуникации между конструкторами,
технологами и другими участниками ЖЦ изделия за счет применения технологий
параллельного проектирования и значительно расширяет количество изменений,
перенося большую их часть на этап проектирования (более раннее выявление ошибок).
3. Благодаря упорядочиванию потока работ значительно сокращается стоимость изменения (в первую очередь, из-за исключения временных потерь).
4. PDM-система практически избавляет конструктора от синдрома «изобретения велосипеда», делает реально возможным широкое заимствование и повторное
использование уже спроектированных деталей. Ранее было проще заново спроектировать узел, чем искать уже существующий, пересматривая горы документации.
Таким образом, PDM-система доводит количество заимствованных компонентов
в изделии до 80 %.
Применение PDM-системы, предполагающей наличие единой целостной модели изделия и четких способов доступа к хранящейся информации, позволяет
значительно улучшить качество данных и, соответственно, повысить качество самого изделия.
Оценить эффективность применения PDM-системы можно на следующем
примере. При работе над проектом спутника связи подразделение космических
систем компании General Dynamics смогло с помощью параллельного проектирования, реализованного на базе PDM-системы, сократить время разработки деталей
в среднем на 21 %, продолжительность всего ЖЦ проектирования – на 43 %, количество изменений – на 73 %, количество рекламаций – на 94 %.
143
Компания IBM смогла на 70 % уменьшить время проведения изменений изделия и на 35 % повысить эффективность выбора покупных деталей. Кроме того, было достигнуто значительное сокращение дублирующих деталей, причем на каждый
процент улучшения выигрыш корпорации составлял более 200 млн долларов.
В фирме Boeing изменение размеров люка на грузовом самолете требовало
5000 часов рабочего времени и занимало до 6 месяцев. За счет применения PDMсистемы это время сокращено до 100 часов.
Примеры PDM
В настоящее время (2006 г.) наиболее известными PDM-системами являются
ENOVIA и SmarTeam (Dessault Systemes), Teamcenter (Unigraphics Solutions),
Windchill (PTC), mySAP PLM (SAP), BaanPDM (BAAN) и российские системы
Лоцман:PLM (Аскон), PDM StepSuite (НПО «Прикладная логистика»), Party Plus
(Лоция Софт).
Основные разработчики САПР в машиностроении считают целесообразным
предлагать комплексные системы PLM, в состав которых входят как модули
CAD/CAM/CAE, так и PDM.
Так, компания Dessault Systemes создает систему ENOVIA на базе приобретенной PDM ProductManager. ENOVIA предназначена для моделирования и управления данными об изделиях, процессах и ресурсах на различных этапах жизненного цикла промышленной продукции от концептуального проектирования до эксплуатационного обслуживания. Это распределенная на базе web-технологий
система управления данными, способствующая интеграции систем проектирования, производства и управления внутри предприятия и позволяющая отдельным
фирмам объединяться в виртуальные предприятия. Управление проектами и изменениями данных, их распределение, интерфейс с системами ERP – далеко не полный перечень функций этой системы.
Кроме ENOVIA Dessault Systemes развивают систему SmartTeam. В базовый
комплект системы SmarTeam входят модуль создания и редактирования моделей,
СУБД (Interbase или Oracle), визуализатор, модуль сопряжения с различными
САПР (в список входят SolidWorks, MDT, Inventor, Microstation, Solid Edge,
AutoCAD 14). Базовый комплект может расширяться путем добавления модулей
документооборота, интеграции с ERP-, SCM- и CRM-системами, взаимодействия с
партнерами через Internet и др. Состав системы SmarTeam и ее связи с CADи ERP-системами иллюстрирует рис. 4.9.
Создаваемая в среде SmarTeam информационная модель объекта состоит из
двух частей. Одна часть служит для описания состава изделия (в виде дерева), его
структуры (в виде файлов с данными о сборках), геометрии и материала деталей.
Другая часть содержит данные о технологических процессах изготовления объекта
в виде дерева операций и переходов и автоматически формируемой технологической документации.
Unigraphics Solutions осуществила преобразование систем iMAN и Metaphase
в новую PDM Teamcenter. В этой PDM имеются подсистемы управления данными
на стадиях проектирования и производства.
144
Рис. 4.9. Состав системы SmarTeam
Компания PTC располагает двумя системами PDM – это Pro/Intralink и более
современная Windchill. Система Windchill основана на использовании Internet
и web-технологий для информационного взаимодействия многих предприятий
и потому может позиционироваться как система CPC. Windchill охватывает все
этапы проектирования, выполняет функции, которые присущи системам документооборота, управления проектами, конфигурацией и изменениями проектных данных. Системы CPC функционируют в гетерогенной среде, охватывающей пространство, не ограниченное рамками отдельных предприятий и корпораций. Система CPC, отвечая на запросы пользователей, может собирать необходимые
данные из web-сайтов, баз данных ERP или PDM систем и, преобразуя в единый
формат, предоставляет их пользователю. Имеются возможности планирования
и моделирования производственных и логистических процессов.
В SolidWorks используется PDM/Works, в SolidEdge – заимствованная система
управления документами SharePoint Portal Server.
Компания Consistent Software разрабатывает оригинальную PDM-систему
OutdoCS PDM и предлагает комплексную систему PartY Plus, разработанную фирмой Лоция Софт. Система PartY Plus предназначена для управления информацией
об изделиях, проектах, сооружениях на протяжении всех этапов их жизненного
цикла. PartY Plus включает в себя три основных продукта, которые могут использоваться как автономно, так и совместно. Это PDM PartY, система управления документами DOCS Open, управления документооборотом и бизнес-процессами LS
Flow. В качестве СУБД нужно использовать одну из систем Sybase Adaptive Server,
MS SQL Server или Oracle.
145
На роль PDM претендует система ведения архива технической документации
и управления проектными данными Search белорусской фирмы Интермех. Search
выполняет функции: хранение документов (чертежи, спецификации, руководства
и др.), поиск и доступ к ним, управление версиями документов и изменениями
в них, визуализация структуры изделий в виде дерева связей, поддержка групповой
работы над проектом (редактирование, маршрутизация документов), формирование различного рода справок и отчетов, регулирование прав доступа к архиву, импорта данных из внешних баз. Архив создается на базе СУБД Oracle или InterBASE
(компания Borland). Обеспечивается удаленный доступ к архиву с помощью webбраузеров. В системе имеются редактор спецификаций, редактор извещений
об изменениях в проекте, модуль доступа к документам, расположенным на других
узлах сети, база данных (электронный архив), текстовый редактор, объединенные
с чертежной системой. Search «понимает» внутренний язык AutoCAD. Для ее использования необходима СУБД Interbase (компания Borlabd).
Белорусская компания Омегасофтвер разработала систему Omega Production,
в которой предусмотрены структурирование данных об изделиях, технологических
процессах, оснастке и оборудовании, управление документами и документооборотом, управление конфигурацией изделий, контроль изменений, вносимых в проект,
интерфейс с другими САПР. Кроме того, в Omega Production имеются модули оперативного управления производством, контроля качества продукции, управления
запасами и поставками материалов и комплектующих, что характерно для
логистических систем. Следовательно, Omega Production может служить основой
для интеграции систем проектирования и управления предприятием.
4.3. УПРАВЛЕНИЕ КОНФИГУРАЦИЕЙ
Среди проблем, для решения которых может использоваться PDM-технология, можно указать также проблему автоматизации управления конфигурацией промышленных изделий.
Управление конфигурацией (УК – Configuration Management) – управленческая
технология, связанная с разработкой, выпуском и поддержкой ЖЦ сложных изделий, производимых во многих вариантах, в том числе – по конкретным требованиям заказчика.
Иными словами – это управленческая технология, устанавливающая и поддерживающая соответствие функциональных, физических и эксплуатационных
свойств (характеристик) изделия заданным требованиям (в том числе требованиям
заказчика), сопоставление технических требований и получающихся значений выходных параметров, управление версиями проекта и внесение изменений в проект.
Эти процедуры необходимо выполнять для обеспечения целостности проектных
данных. Если в проект нужно внести изменения, то создается новая версия проекта, основанная на первоначальном проекте, и изменения вносятся уже в эту новую
версию. Исходный вариант проекта при этом сохраняется в прежнем виде. Одна
версия каждого объекта является текущей или активной версией. Если имеется несколько версий объекта, то текущей является та, которая последней подвергалась
изменениям.
146
В системе BaanPDM принята следующая схема управления версиями. Если
версия объекта создана впервые, ей назначается статус «неопределенная». Если
версия объекта готова для общего доступа, ее следует занести в сборник, и затем
BaanPDM назначает ей статус «готово к выпуску». Выпуск объекта делает его описание доступным для использования в других подразделениях и производства. Если кто-либо желает сделать изменения в готовой к выпуску версии объекта, он
должен извлечь ее из сборника. Этой версии присваивается статус «находящаяся
в процессе изменения», который показывает, что готовится новая версия, а новой
версии – неопределенный статус.
В некоторых PDM были предусмотрены следующие статусы для версий документов: рабочий – версия c таким статусом находится в работе, ее можно модифицировать; принятый – именно версия с этим статусом является основой для
взаимодействия частей проекта, она служит для обмена данными между объектами, ее модификации осуществляются через рабочий статус; архивный – статус,
присваиваемый предыдущим сохраняемым версиям; порождаемый – статус
зарезервирован для вновь создаваемых объектов, например при синтезе проектных
решений. Разработчик сам изменяет статус объектов.
Аналогично в системе PDM STEP Suite одна из версий проекта является рабочей (активной), с ней работают пользователи. Но можно обращаться и к любой
другой версии. В процессе коллективной работы хранимый в БД документ, чертеж
или модель могут быть взяты для дальнейшей проработки. Тогда исходная версия
документа помечается как находящаяся в процессе редактирования. После редактирования созданная новая версия хранится вместе с предыдущей. При этом
для каждой версии документа можно определить породившую ее исходную версию.
В PDM Teamcenter предусмотрены сохранение истории внесения изменений
в проект, верификация характеристик изделия после внесения изменений, реализация наследования атрибутов базовой конфигурации и т. п.
За рубежом технология управления конфигурацией получила широкое распространение, о чем свидетельствуют многочисленные нормативные документы.
Для отечественной промышленности технология УК является сравнительно новой,
и ее применение связано с рядом специфических проблем, первой из которых является правильное понимание термина «конфигурация» и всех производных от него,
включая понятие «управление конфигурацией».
Эта проблема состоит в том, что в русском языке слово «конфигурация» несет
вполне определенную семантическую нагрузку. Согласно «Толковому словарю
русского языка» С. И. Ожегова и Н. Ю. Шведовой «Конфигурация – внешнее очертание, а также взаимное расположение предметов или их частей». В узком смысле
под конфигурацией понимают структуру и состав изделия.
Такая трактовка существенно отличается от смысла, который вкладывается
в это понятие зарубежными источниками, что порождает многочисленные разночтения. Для их преодоления необходимо сформулировать корректные определения,
которые позволили бы в дальнейшем построить теорию, методологию, а затем и технологию УК, которые, с одной стороны, отвечали бы смыслу зарубежных норматив147
ных документов, а с другой – были полностью и однозначно понимаемы отечественными специалистами.
Приводимое ниже определение сформулировано на основе анализа аналогичных определений, содержащихся в различных литературных источниках. Анализ
позволил устранить разночтения, содержащиеся в различных нормативных документах, и предложить формулировку, основанную на понятии информационной модели (ИМ).
Конфигурация (Configuration): в соответствии с документом ИСО 10007
«Quality management systems – Guidelines for configurations management» структура
предполагаемого к разработке, разрабатываемого или существующего изделия,
обладающая функциональными физическими и эксплуатационными свойствами
(характеристиками), отвечающими установленным требованиям, и отображаемая
в различных информационных моделях, соответствующих стадиям ЖЦ этого изделия.
Технология управления конфигурацией призвана решать противоречивые по
своей сути задачи: с одной стороны, обеспечивать максимальное удовлетворение
требований заказчика к изделию в течение всего ЖЦ, а с другой – обеспечивать
максимально возможный в этих условиях уровень унификации компонентов выпускаемых изделий. Управление конфигурацией актуально также тогда, когда
на основе некоторой базовой модели (конструкции) изделия создаются его различные модификации.
Эта технология предполагает выполнение следующих операций (по ИСО
10007):
• идентификацию конфигурации, т. е. присвоение ее текущей версии определенного «имени» (кодового обозначения);
• контроль конфигурации, т.е. получение подтверждения того, что текущая версия изделия соответствует техническим требованиям. При отрицательном результате
проверки: анализ причин невыполнения требований и документально оформленное
инициирование работ по внесению изменений в конструкцию (как правило, посредством замены или переделки отдельных узлов или агрегатов);
• учет статуса конфигурации;
• проверку (аудит) конфигурации.
Стартовая точка УК – установление, согласование между заказчиком и поставщиком и формализация контрактных требований, из которых ясно следуют
обязательства поставщика. Важным результатом УК является тот факт, что потребителю поставляется не только само изделие, но и документированные доказательства того, что изделие и все его компоненты соответствуют заданным требованиям. Это, с одной стороны, служит основой гарантии качества, а с другой – защищает поставщика от необоснованных претензий.
Технология УК обеспечивает целостность и документирование всех данных
об изделии, «прослеживаемость» (traceability) всех шагов, связанных с внесением
изменений в структуру, состав и конструкции отдельных компонентов изделия.
Это позволяет в любой момент воспроизвести процесс изготовления экземпляра
изделия с гарантией получения его требуемых характеристик.
148
Документация конфигурации (ДК, configuration documentation – CD):
документация, позволяющая определить и идентифицировать функциональные, физические и эксплуатационные характеристики изделия. В качестве документации конфигурации (ДК) принято рассматривать технические требования (условия), чертежи изделия или электронные данные аналогичного назначения.
Базовая конфигурация (baseline): утвержденная в установленном порядке документация конфигурации.
Концепция изделия (КИ, Product Concept – PC): понятие, описывающее класс
подобных изделий, которые предприятие предлагает заказчикам. КИ – идея изделия
(рис. 4.10), отвечающая заданному набору технических требований (Specification),
требованиям заказчиков («Облик изделия» или «Лицо изделия»). С точки зрения
заказчика концепция изделия представляет обозначение формализованного набора
требований (Specification), отражающих потребности заказчика. С точки зрения
производителя концепция изделия – это обозначение семейства модификаций изделия, поставляемых на рынок.
Рис. 4.10. Определение объекта Product Concept в модели NPDM
В модели SPS (рис. 4.11) концепция изделия рассматривается в маркетинговом контексте (product concept context).
Рис. 4.11 Определение объекта Product Concept в STEP PDM Schema
149
В NPDM концепция изделия рассматривается в контексте одного или нескольких сценариев использования (usage scenario).
Технические требования (Specification) могут быть логически разделены
на группы (Specification Category). Примерами таких групп могут быть тактикотехнические характеристики, требования безопасности, экологические требования
и т. д.
Для объектов, составляющих технические требования, могут быть заданы логические условия их интерпретации (Specification Expression, рис. 4.12): 'and', 'or',
'one of, 'not'.
Рис. 4.12. Классификация технических требований и бинарные отношения между элементами требований в модели NPDM
В стандарте ИСО 10303, спецификации SPS и модели NPDM понятию объект
управления конфигурацией (Объект конфигурации (ОК) – Configuration Item – CI)
соответствует любое техническое или программное средство (или их комбинация),
выполняющее конечную функцию (или некоторую функцию конечного изделия),
выделенное для целей управления конфигурацией и обладающее определенным
набором свойств (характеристик). Один объект конфигурации может входить
в другой и, в свою очередь, включать в себя другие объекты конфигурации
(рис. 4.13). Конфигурация в целом и составляющие ее ОК могут быть соответствующим образом документированы и утверждены. ОК обычно обозначают уникальным буквенно-цифровым идентификатором (кодом), который используется
также в качестве неизменяемой части для серийных номеров и уникальной идентификации отдельных компонентов (блоков) этого ОК.
Иерархия объектов конфигурации и их взаимодействие описываются при помощи конструкции CONFIGURATIONITEM RELATIONSHIP. Для объектов
150
конфигурации могут быть установлены правила применяемости (CONFIGURATION_EFFECTIVITY), связанные с серийными номерами изделий (serial numbered
affectivity), обозначениями партий изделий (lot_affectivity) и календарными датами
(dated affectivity).
PRODUCT CONCEPT
Концепция изделия
Id
Идентификатор
Name
Обозначение
Description
Описание
Market_context
Сегмент рынка
CONFIGURATION ITEM
Объект конфигурации
Id
Идентификатор
Name
Обозначение
Description
Описание (опция)
Item concept
Ссылка на концепт изделия
Purpose
Назначение (опция)
CONFIGURATION ITEM
RELATIONSHIP
Name
Отношение между объектами конфигурации
Description
relatingconfigurationitem
Описание отношения
Ссылка на родительский объект конфигурации
related configuration item
Ссылка на дочерний объект конфигурации
CONFIGURATION_EFFECTIVITY
Правило применения конфигурации
Наименование отношения
Рис. 4.13. Взаимосвязь объектов, используемых в управлении конфигурацией изделия (см. также с. 152)
151
product definition affectivity
Объект, для которого задано правило применяемости
serial numbered affectivity
Применяемость по серийному номеру
dated affectivity
Применяемость по дате
lot affectivity
Применяемость по обозначению партии
Id
Обозначение правила применяемости
Usage
Ссылка на отношение, для которого задается
применяемость
Серийный номер изделия, начиная с которого действует
правило применяемости
Серийный номер изделия, до которого действует
правило применяемости
Дата, начиная с которой действует правило
применяемости.
Дата, до которой действует правило применяемости
affectivity start id
affectivity end id
affectivity start date
affectivity end date
affectivity lot id
Обозначение партии, для которой действует правило
применяемости
Рис. 4.13. Окончание
Функциональная базовая конфигурация (ФБК): утвержденный комплект ДК
(функциональная ДК), описывающий требования (заказчика) к изделию и его
свойствам, а также проверки, необходимые для демонстрации выполнения этих
требований.
Проектная базовая конфигурация (ПБК): утвержденный комплект ДК, созданный при разработке проекта и содержащий помимо чертежей и иных проектных
документов сведения, подтверждающие выполнение требований к изделию и его
компонентам на стадии проектирования (результаты расчетов, математического
и/или натурного моделирования и т. п.).
Физическая базовая конфигурация (ФзБК): утвержденная ДК, созданная при
изготовлении конкретного экземпляра изделия, содержащая помимо чертежей, спецификаций и иных необходимых документов результаты выходного контроля
и испытаний, подтверждающие выполнение требований.
В общем виде управление конфигурацией согласно ИСО 10007 включает в себя
4 основных этапа, связанных с выполнением предпроектных работ, проектированием,
производством и эксплуатацией (рис. 4.14).
Для управления конфигурацией назначается специальное лицо – менеджер по
конфигурации (Configuration Manager), в должностные обязанности которого вводится выполнение следующих функций:
1.Оформление и утверждение базовой конфигурации.
2. Идентификация конфигурации – присвоение имени (кода).
3. Проверка конфигурации – подтверждение соответствия требованиям
(контроль).
4. Анализ несоответствий и инициирование изменений (аудит).
5. Контроль результатов изменения.
7. Корректировка базовой конфигурации. Учет статуса.
152
Рис. 4.14. Управление конфигурацией: ФК – функциональная конфигурация; ФБК – функциональная
базовая конфигурация; ПК – проектная конфигурация; ПБК – проектная базовая конфигурация;
ФзК – «физическая конфигурация»; ФзБК – «физическая» базовая конфигурация
При разработке базовой конфигурации необходимо управлять требованиями
(Requirement Management), которые появляются в результате проектирования изделий. Основные правила управления требованиями включают:
• формализацию требований;
• структурирование требований;
• проверку требований на выполнимость и непротиворечивость;
• управление изменениями в требованиях.
Управление конфигурацией базируется на нормативных документах:
• MIL-STD-480 Configuration Control;
• MIL-STD-481 Configuration Control;
• MIL-STD-483 Configuration Management Practices;
• MIL-STD-973 Configuration Management;
• MIL-STD-2549 Configuration Management Data Interface;
• STANAG 4159 NATO Material Configuration Management Policy;
• STANAG 4188 NATO Material Configuration Management Procedures;
• IEEE Std 828 Software Configuration Management Plans;
• IEEE StdlO42 Guide to Software Configuration Management;
153
• MIL-HDBK-61 Configuration Management Guidance;
• ISO 10007 Quality Management – Guidelines for Configuration Management.
Следует еще раз подчеркнуть, что УК является одной из базовых управленческих технологий и имеет целью обеспечить максимальное удовлетворение требований потребителя. В этом является связь УК с менеджментом качества.
Заметим, что в процессе используются измеримые характеристики изделия,
на основании которых можно судить о состоянии и ходе производственных процессов и непрерывно их совершенствование.
4.3.1. КОНТЕКСТЫ УПРАВЛЕНИЯ КОНФИГУРАЦИЕЙ
Содержание понятий конфигурации и УК зависит от того, в каком контексте
они применяются. Ниже рассматриваются некоторые из этих контекстов.
Потребительский контекст. Главная задача заказчиков сложных технических систем – формулирование и отслеживание требований, которые обязан выполнить поставщик. В качестве такого заказчика применительно к военной технике обычно выступают государственные (правительственные) учреждения. В этом
контексте УК выглядит как многоступенчатый процесс формирования и анализа
многообразных требований к свойствам и структуре изделия, а также как многократное подтверждение того, что эти требования выполняются на разных стадиях
ЖЦ изделия.
На начальных стадиях этого процесса формируется и анализируется укрупненная информационная модель (ИМ), отображающая структуру изделия и входящие в нее основные ОК – функциональные умы (системы) изделия (например,
для самолета – планер, силовая установка, авионика и т. п.). Задача УК с точки
зрения (в контексте требований) заказчика состоит в следующем:
• в «декомпозиции» общих требований к изделию таким образом, чтобы выделить из них группы, которые можно однозначно связать с конкретными ОК; эти
группы включаются в состав ИМ в форме желаемых свойств;
• в формировании ИМ функциональной структуры изделия, состоящей
из выделенных ОК, оформлении и утверждении соответствующей БК (создании
функциональной БК);
• в сопоставлении требований к ОК, входящим в функциональную БК,
со свойствами конкретных технических решений, реализующих ОК, в том числе
посредством расчетных методов и моделирования;
• в выявлении отклонений и принятии решений об изменении в конструкции
изделия и ОК с целью сближения заданных требований и получаемых характеристик; в проверке эффективности принятых решений с точки зрения достижения
этой цели;
• в проверке корректности ИМ, отображающей принятые изменения.
Для выполнения перечисленных действий заказчик и поставщик (разработчик) назначают уполномоченных лиц – менеджеров по конфигурации. После реализации и соответствующего документирования изменений процесс оценки
свойств и характеристик повторяется, равно как может повторяться и весь
описанный цикл. В результате при необходимости исходная функциональная БК
может быть скорректирована и заменена новой.
154
Этот цикл может повторяться и на последующих стадиях ЖЦ изделия: после завершения процесса проектирования, изготовления и испытаний опытного образца,
установочной серии, головного образца, а также в процессе использования изделия
по назначению, когда могут быть скорректированы ранее выставленные требования
или произведена замена компонентов. В ходе этих циклов, естественно, должны выполняться все операции, предусмотренные технологией УК.
Конструкторский контекст. Конструкторский контекст возникает с началом
процесса проектирования изделия и сохраняет силу на последующих стадиях ЖЦ.
В этом контексте на базе ИМ, отображающей функциональную БК, формируется
проектная БК, которая используется в последующих контекстах: технологическом, производственном, эксплуатационно-ремонтном и т. д.
В процессе проектирования первоначально созданная ИМ преобразуется в новую – проектную – ИМ, в которой исходные ОК декомпозируются на ОК низших
рангов, что необходимо для рациональной организации разработки и проектирования основных функциональных компонентов изделия (систем, агрегатов, узлов и т. д.).
При этом технические требования к ОК наследуются из предыдущего контекста
и используются как основа для принятия технических (проектных) решений как по
изделию в целом, так и по его компонентам (узлам, агрегатам, сборочным единицам и т. д.), т. е. ОК низших рангов.
В конструкторском контексте общие технические требования к изделию преобразуются (декомпозируются) в конкретные технические требования и технические
условия, которым должны удовлетворять компоненты (ОК) по всем принятым
в рассмотрение уровням. Все это находит отражение в проектной ИМ. Свойства конкретных реализаций проверяются на соответствие этим требованиям расчетными,
модельными и экспериментальными методами.
Подход, основанный на декомпозиции требований, на первый взгляд представляется единственно возможным для логического решения задачи УК в конструкторском контексте, ибо позволяет выполнять поэлементный анализ соответствия ОК
заданным требованиям. При этом, однако, могут выпасть из рассмотрения «синергетические эффекты», т. е. эффекты, возникающие во взаимодействии элементов.
Эта проблема требует специфических решений в конкретных ситуациях.
Конструкторский контекст УК требует введения в рассмотрение еще нескольких понятий, используемых в системе разработки и постановки продукции на производство (СРПП), принятых в российской промышленности. Важнейшими из них
являются следующие:
• базовое изделие;
• модификация;
• исполнение;
• семейство изделий.
В отечественной нормативной документации этим понятиям даются следующие определения.
Базовое изделие – изделие, для которого на некоторую дату разработан и утвержден в установленном порядке полный комплект технической документации.
155
Базовое изделие является основой, относительно которой разрабатываются модификации и исполнения.
Модификация изделия – разновидность изделия из семейства изделий
(см. ниже), создаваемая на основе базового изделия с целью расширения или специализации сферы его использования. Создание модификаций – один из видов
разработки, которая в зависимости от задач может сводиться: к изменению компоновки составных частей, конструкции рабочих органов или органов управления,
изменению внешнего вида и т. д.
Обычно создание модификации связано с изменением функциональности изделия, обусловленным упомянутым в определении расширением (в сторону большей универсальности) или сужением (специализацией) сферы его применения.
Примеры:
Модификации самолета – пассажирский, военно-транспортный, санитарный
на одной и той же базе.
Модификации автомобиля – пассажирский, грузопассажирский, санитарный,
технической помощи и т. д.
Модификации станка – универсальный (база), специальный для обработки
конкретной детали или группы деталей и т. д.
Исполнение изделия – разновидность изделия из семейства изделий, создаваемая на основе базового изделия с целью обеспечить его использование в специфических условиях окружающей среды или с целью удовлетворить специфические
требования заказчика, например в отношении комфортности (как правило, без изменения функциональности). Создание исполнений – один из видов разработки,
заключающийся в применении к изделию и/или его компонентам особых видов
покрытий, способов окраски, пропитки, отделки (внешней) и т. д.
Примеры: тропическое исполнение, арктическое исполнение, экспортное исполнение и т. п.
Семейство изделий: базовое изделие и все разновидности (модификации, исполнения), создаваемые на его основе.
Функциональные и проектные конфигурации модификаций и исполнений отличаются от соответствующих конфигураций базового изделия, поскольку обладают несколько иными характеристиками и удовлетворяют измененному набору
требований.
Это отражается в идентификаторах модификаций и исполнений. Такие идентификаторы, как правило, наследуют общую группу идентификационных символов, соответствующих базовому изделию и указывающих на принадлежность
к семейству, а также имеют уникальные символы, отличающие модификации
и исполнения друг от друга внутри семейства.
Пример: семейство автомобилей ВАЗ 2110. Модификации: ВАЗ 2111, ВАЗ 2112.
Во избежание путаницы следует подчеркнуть отличие понятия базового изделия от понятия базовой конфигурации, которые иногда ошибочно полагают тождественными. Суть отличия состоит в том, что для базового изделия, как и для любой
модификации и любого исполнения, могут быть созданы функциональная и проектная БК.
156
По существу, любая БК представляет собой зафиксированную на некоторый
момент времени структуру, присущие ей свойства и значения этих свойств. Относительно этой структуры в процессе уточнения требований к изделию и проектирования проводятся изменения, после утверждения которых создаются новые БК.
Этот процесс схематически показан на рис. 4.15. Отсюда следует, что понятие БК
несколько шире понятия базового изделия. Это достаточно тонкое отличие может
сыграть определенную роль при решении проблемы унификации компонентов
изделий.
Рис. 4.15. Процесс формирования базовых конфигураций:БИ – базовое изделие; М1, М2 ... – модификации;
ИС1, ИС2 ... – исполнения; ФБК0 – «нулевая» функциональная базовая конфигурация; OBKN – N-я функциональная базовая конфигурация; ПБК0 – «нулевая» проектная базовая конфигурация; ПБКМ – М-я проектная
базовая конфигурация
В соответствии с описанными понятиями рассмотрим более подробно операции, из которых состоит технология управления конфигурацией:
1. Идентификация конфигурации:
• группирование требований, выделение ОК, «отвечающих» за отдельные
группы функциональных и иных характеристик изделия, введение обозначений;
• утверждение функциональной ДК и идентификация ФБК.
2. Контроль конфигурации:
• установление связей между ОК и конструкторскими данными, которые
должны содержать оценки характеристик изделия, полученные расчетными или
экспериментальными методами (в зависимости от стадии ЖЦ);
• сопоставление полученных данных с требованиями, содержащимися в ОК,
обнаружение ОК и соответствующих им конструктивных элементов, «ответственных» за отклонение от требований;
157
• внесение и документирование изменений в конструкцию изделия и его элементов с целью устранения отклонений от требований;
• установление последовательности (очередности) внесения и утверждения
изменений; идентификация изменений;
• оценка эффективности реализованных изменений в отношении степени
удовлетворения требований и связанных с этим затрат.
3. Учет статуса конфигурации: процедура систематической проверки и документального оформления наличия утверждений ОК, БК всех видов и иных объектов, относящихся к конфигурации.
4. Аудит конфигурации: совокупность процедур систематической проверки
соответствия между требованиями, предъявляемыми к изделию и его компонентам, и их фактическими свойствами (характеристиками), выполняемая на всех стадиях ЖЦ.
В конкретных производственных ситуациях возможны некоторые вариации
описанной технологии, в том числе относящиеся к формированию базовых конфигураций, модификаций и исполнений изделия, как по инициативе заказчика, так и
по инициативе предприятия – разработчика и поставщика изделия.
Отметим, что технология УК применима только к изделиям, имеющим достаточно сложную функциональную структуру. Из нее могут быть выделены ОК, выполняющие в составе конечного изделия четко определенные функции и обладающие значимым набором характеристик, сопоставимых с подмножеством требований, предъявляемых к конечному изделию.
4.3.2. ИНФОРМАЦИОННЫЕ АСПЕКТЫ УПРАВЛЕНИЯ КОНФИГУРАЦИЕЙ
В п. 4.3 вводится понятие Product Concept – «концепция изделия» (КИ), описывающее класс подобных изделий, которые организация (предприятие) предлагает своим покупателям (потребителям, заказчикам). КИ представляет идею изделия,
которая отвечает потенциальным или реальным требованиям покупателей. КИ может быть сформирована на основании маркетинговых исследований, т. е. задолго
до того, как изделие получит конструктивное или материальное воплощение. По
физическому смыслу КИ можно трактовать как обозначение и (необязательно)
краткое описание основных свойств семейства изделий. Иными словами, КИ –
чисто информационное понятие, которое может выглядеть, например, следующим
образом.
Концепция изделия:
• Обозначение (идентификатор) – ВАЗ 2110;
• Наименование (имя) – Лада;
• Описание – Автомобиль легковой, малолитражный, с передним приводом и
базой 2600 мм;
• Сегмент рынка – Средний класс в ценовом диапазоне до $ 10 000;
Каждой КИ может быть поставлен в соответствие набор требований (характеристик), например в виде табл. 4.1.
158
Таблица 4.1
НАБОР ТРЕБОВАНИЙ К ИЗДЕЛИЮ
№
п/п
Наименование параметра
Характеристика
1
Масса, кг
Не более 900
2
Масса снаряженная, кг
Не более 1200
Дизель (Д)
3
С наддувом (НД)
Без наддува (БНД)
Двигатель
Бензиновый (Б)
Карбюраторный (К)
Инжекторный (И)
4
Рабочий объем, л
1,4–2,0
5
Мощность, л.с.
80,0–140,0
6
Трансмиссия
Механическая с ручным
управлением (МКП)
С автоматическим управлением
(АКП)
Седан
7
Кузов
«Наследуемый»
из предыдущей серии
Оригинальный
Универсал
Оригинальный
Эта таблица указывает на три важных факта:
1) она содержит функциональную структуру конечного изделия (выделенные
жирным шрифтом слова в левом столбце), т. е. сведения о компонентах, которые
в дальнейшем можно рассматривать как ОК;
2) она содержит классификационные (качественные) признаки компонентов,
которые в контексте заказчика могут рассматриваться как требования к конечному
изделию (желаемые свойства), а также количественные характеристики, обеспечиваемые компонентами;
3) она показывает, что требования (свойства) могут быть представлены
в форме древовидного графа, отражающего отношения классификации.
На рис. 4.16 показана функциональная структура изделия. Будучи документально оформленной и утвержденной в установленном порядке, такая структура
приобретает статус ФБК. Адекватное описание этой структуры в информационной
среде есть исходная ИМ изделия. Ее компоненты можно в дальнейшем рассматривать как ОК. При этом КИ можно трактовать как ОК нулевого уровня, а компоненты – как ОК первого уровня.
159
Рис. 4.16. Функциональная структура изделия
Эту схему можно развить, включив в нее более подробные данные о модификациях (исполнениях) каждого компонента, что и сделано (частично) на рис. 4.17,
который отображает все три отмеченных выше факта. В этом случае мы вправе трактовать элементы (вершины) получившегося дерева как ОК низших уровней (2-го,
3-го, 4-го и т. д.). Следует при этом помнить, что вершины дерева в рассматриваемом примере отображают свойства и/или требования к компонентам, а само дерево – расширенный классификатор ОК.
Рис. 4.17. Графическое представление данных табл. 4.1: Д – дизель; БНД –
без наддува; НД – с наддувом; Б – бензиновый; К – карбюраторный; И – инжекторный; АКП – автоматическая коробка передач; МКП – механическая коробка
передач
Например, выделяя в дереве подграф, вершины которого обозначены серым
цветом, заказчик формулирует следующее требование:
«Требуется автомобиль из семейства ВАЗ 2110 с двигателем бензиновым,
инжекторным, с рабочим объемом 1,8 л».
Возможен иной способ задания требований и характеристик, при котором
с каждым элементом функциональной структуры (рис. 4.16) ассоциируется таблица
характеристик (рис. 4.18).
160
Класс
Тип
Объем, л
1,6
1,8
2,0
Дизель
С наддувом
Дизель
Без наддува
Бензиновый
Карбюраторный
1,6
1,8
2,0
Бензиновый
Инжекторный
1,6
1,8
2,0
1,6
1.8
2,0
Рис. 4.18. Функциональная структура с ассоциированной таблицей характеристик
Выбирая строку из этой таблицы, заказчик формулирует свое требование
так же, как указано выше. Из вышеизложенного можно сделать следующие
важные выводы.
1. Если в графе типа рис. 4.17 для каждого ОК, образующего уровень ОК-1,
выделить единственный подграф (маршрут), приводящий к некоторой конечной
вершине, то мы получим новый граф, однозначно отображающий требования
к модификации или исполнению изделия (но еще не само изделие). Вершины этого
нового графа будут представлять множество ОК в пользовательском контексте.
С другой стороны, множество таких графов служит функциональным описанием
семейства изделий, порожденного одной КИ.
2. Тот же результат можно получить из представления типа рис. 4.18, если
из каждой таблицы, ассоциированной с ОК уровня ОК-1, выбрать по единственной
строке и таким образом построить полный набор требований к модификации или
исполнению изделия при существенно меньшем числе ОК. Множество подобных
описаний также может служить общим функциональным описанием семейства изделий, порожденного одной КИ.
3. Схема на рис. 4.19 является обобщенным результатом двух описанных выше
способов. Здесь КИ-0 – концепция изделия, содержащая общие требования к семейству изделий. ОК 01...OK On представляют описания функциональных конфигураций модификаций и исполнений изделий, входящих в класс КИ-0, т. е. структурированные и идентифицированные наборы требований к модификациям
и исполнениям (ОК высшего уровня). Эти наборы одним из описанных выше двух
способов декомпозируются на «поднаборы», относящиеся к функциональным компонентам и идентифицированные как
OK 0j-1 OK 0j – m (j = 1:n).
161
На схеме число «поднаборов» – одинаковое для каждого образа функциональной
конфигурации, хотя, строго говоря, это не всегда так, поскольку помимо основного
комплекта компонентов в отдельные конфигурации могут входить дополнительные
опции, однако сути дела это не меняет.
Некоторые компоненты могут быть элементами своих классов, т. е. быть ОК, относящимися к своим КИ (КИ-1, ..., КИ-m). На схеме ОК каждого уровня относятся
к одному классу (например, все автомобили семейства ВАЗ 2110 оснащаются только
бензиновыми двигателями), что, впрочем, совершенно не обязательно. Другие же
могут изначально не принадлежать известному классу и требуют специальной разработки. Для них соответствующий «поднабор» требований должен быть подвергнут
дальнейшей декомпозиции (см. ОК 03-к).
Рис. 4.19. Представление конфигураций в семействе изделий
Документированный результат описанного выше процесса образует множество функциональных конфигураций изделий, относящихся к семейству изделий,
порожденному одной КИ. После того как в контакте потребителя и разработчика
подобная структура, связанная с формированием, декомпозицией и идентификацией требований, создана в форме соответствующей ИМ, необходим переход в конструкторский контекст, т. е. выбор и принятие конструкторских решений, результатом чего является проектная конфигурация. Здесь создается новая ИМ, в которой
каждому ОК должны быть поставлены в соответствие объекты типа Product Definition, Product Definition Formation и другие подобные сущности.
162
В состав такой ИМ входят специальные информационные объекты, определяющие конкретное конструкторское решение, соответствующее идентифицированному в ОК набору требований. Если для компонента изделия (модификации, исполнения) существуют готовые решения (имеющиеся в продаже или ранее
спроектированные), то задача сводится к поиску подходящего варианта в соответствующей базе данных (каталоге, архиве и т. п.). При этом данные, содержащиеся
в ОК, служат поисковым образом. Результат поиска может оказаться не единственным. В этом случае придется либо задавать дополнительные требования (т. е.
корректировать ОК), либо (при равноценности найденных решений) воспользоваться правилами применяемости, либо принимать волевое решение.
Если готовых решений нет, то начинается процесс проектирования отсутствующих компонентов, в ходе которого описанная выше процедура может быть
применена к компонентам низшего уровня (см. рис. 4.18).
Таким образом, на множестве ИМ, создаваемых на последующих стадиях ЖЦ
(и в различных контекстах), устанавливается и прослеживается соответствие между деревом требований и конструкторским деревом изделия (т. е. между функциональной и проектной конфигурациями). Иными словами, обеспечивается согласование требований и фактических свойств изделия, что и является основным смыслом технологии УК.
Сформированная описанным способом, документированная и утвержденная
в установленном порядке проектная конфигурация приобретает статус ПБК.
Здесь следует отметить несколько важных обстоятельств.
1. Число уровней в дереве требований, как правило, не слишком велико. В частности (рис. 4.16, 4.17) это дерево может иметь одну общую вершину и один уровень конечных вершин (т. е. быть «звездным» графом). Конструкторское дерево
должно иметь такое число уровней, которое полностью (до деталей) описывает
изделие.
2. Вершины дерева требований помечаются идентификаторами, соответствующими классам (подклассам, группам) компонентов. Метки вершин конструкторского дерева должны содержать обозначения (номера) конструкторских документов, в соответствии с которыми эти компоненты могут быть изготовлены.
3. Некоторые требования (например, общая масса автомобиля в табл. 4.1) изначально не всегда могут быть декомпозированы применительно к ОК, входящим
в состав дерева требований. Зато в конструкторском дереве с любой его вершиной
может быть ассоциирована соответствующая характеристика (масса), так что
непосредственным суммированием по дереву может быть найдена общая масса
изделия и установлено, выполняется или не выполняется требование.
Все описанные выше и другие графы, порождаемые в процессе проектирования, и связанные с их вершинами и ребрами объекты (характеристики, документы,
правила и т. д.) отображаются последовательностью развивающихся и уточняемых
ИМ. Технология УК позволяет воздействовать на этот процесс таким образом,
чтобы обеспечить сближение (в пределах допуска) требований и фактических
свойств изделия и ОК.
163
4.3.3. СЦЕНАРИИ УПРАВЛЕНИЯ КОНФИГУРАЦИЕЙ
Практическое применение технологии УК зависит от конкретной организационно-производственной ситуации. Рассмотрим некоторые из таких ситуаций.
1. Базовое изделие и его разновидности (модификации и исполнения), т. е. семейство, уже созданы и выпускаются в серийном, крупносерийном или даже массовом производстве (характерный пример – автомобили). Кроме основного семейства в производстве (основном или смежном) освоены дополнительные компоненты, которые могут устанавливаться на все или некоторые разновидности семейства
по заказу потребителя (покупателя). Для этих дополнительных компонентов разработчик заранее предусмотрел посадочные (установочные) места, электрические
присоединения и т. п., т. е., по существу, правила и возможности совместимости
этих дополнительных компонентов с изделиями семейства. Информация о семействе хранится в PDM-системе разработчика и производителя (оптимальный способ
такого хранения – предмет отдельного рассмотрения). Там же хранится информация о дополнительных компонентах.
Потребителю в этом случае информация об изделиях семейства и дополнительных компонентах предоставляется в форме каталогов, бланков заказа и других
подобных документов, на основе которых он сопоставляет свои требования с возможностями поставщика (производителя) и делает тот или иной выбор.
Управление конфигурацией в описанной ситуации является внутренним делом производителя и разработчика (в частности – службы качества) и предполагает решение следующих задач:
• периодически проверять соответствие выпускаемых изделий общим требованиям и конкретным требованиям, относящимся к модификациям и исполнениям
(аудит конфигурации, который выполняется подразделением УК в составе службы
качества);
• изучать предложения маркетинговой службы и службы качества (по рекламациям и иным претензиям потребителей) в части совершенствования базы, моделей семейства и дополнительных компонентов и при необходимости и целесообразности инициировать внесение изменений в конструкции с последующим их отслеживанием в проектировании и в производстве;
• обеспечивать своевременную подготовку сопроводительной документации
на изменяемые компоненты;
• при запуске в производство партий изделий семейства (или отдельных экземпляров) обеспечивать комплектность и актуальность рабочей конструкторской
документации (РКД) и т. д.
2. Существуют базовое изделие (база) и набор дополнительных компонентов.
Разработаны технологии, основные виды технологической оснастки и т. д. И база,
и все компоненты хотя бы один раз были изготовлены. Изделия выпускаются малыми партиями или даже индивидуально по заказам потребителей. Для большинства дополнительных компонентов проработаны установочные места, присоединительные размеры, электрические и гидравлические соединения и т. д. Информация
164
о базе, дополнительных компонентах, ранее выпущенных экземплярах изделий
и связанной с ними документацией хранится в PDM-системе предприятия.
Потребителю доступна информация о характеристиках базы и дополнительных компонентов. При заказе изделия (партии) потребитель на основе этой информации формулирует свои требования, которые могут быть четырех видов:
2.1. Не требовать изменений базы и дополнительных компонентов, а касаться
только комплектации изделия имеющимися компонентами.
2.2. Требовать внесения изменений в базу без изменения дополнительных
компонентов, которые выбираются из имеющегося набора.
2.3. Требовать разработки отсутствующих дополнительных компонентов
без изменения базы.
2.4. Требовать изменения базы и разработки отсутствующих дополнительных
компонентов.
В этой ситуации служба УК включается в работу на стадии подготовки контракта.
В случае 2.1 служба УК должна:
• найти в PDM-системе предприятия вариант изделия, наиболее близкий
(по составу дополнительных компонентов) к требованиям заказчика;
• согласовать с конструкторской службой возможности и сроки подготовки
нужного комплекта документации;
• выдать информацию финансово-экономическим службам для расчета контрактной цены;
• после заключения контракта обеспечить передачу требуемого комплекта
РКД в производство;
• после завершения изготовления изделия убедиться в его соответствии
(по составу компонентов) контрактным требованиям и обеспечить подготовку необходимого комплекта сопроводительной документации;
• убедиться в том, что данные об изделии внесены в PDM-систему предприятия и т. д.
В случае 2.2 служба УК должна:
• выступать посредником между разработчиками и заказчиком при переговорах о технических и юридических возможностях (в смысле изменения разрешений,
сертификатов и т. д.) внесения требуемых заказчиком изменений в базу;
• при положительном завершении переговоров участвовать в разработке ТЗ
на внесение изменений в базу, отслеживать его реализацию в проектировании
и производстве;
• в остальном – см. случай 2.1.
В случае 2.3 служба УК должна:
• выступать посредником между разработчиками и заказчиком при переговорах о технических и юридических возможностях (в смысле изменения разрешений,
сертификатов и т. д.) разработки дополнительных компонентов;
• при положительном завершении переговоров участвовать в разработке ТЗ на
создание нового компонента (включая возможности его сопряжения с базой), отслеживать его реализацию в проектировании и производстве;
• внести сведения о новом дополнительном компоненте в перечень компонентов, предлагаемых заказчикам;
• в остальном – см. случай 2.1.
165
В случае 2.4 – см. случаи 2.2 и 2.3.
Во всех описанных выше ситуациях и случаях служба УК – служба управления конфигурацией поставщика (разработчика).
Однако в соответствии с представлениями зарубежных нормативных документов могут существовать и принимать участие в описанных процессах и процедурах службы УК заказчика (в первую очередь, для изделий, заказываемых и поставляемых для государственных нужд, в том числе для армии). В этом случае таким службам принадлежит решающая роль в формировании и согласовании всех
требований к изделию, в процедурах выходного контроля и приемки изделий,
а также в сборе и передаче поставщику данных об отклонениях от требований, выявленных в процессе использования изделий по назначению.
3. Создание нового изделия по инициативе заказчика. Базового изделия нет.
У заказчика имеется представление о том, как должно выглядеть и каким основным требованиям должно удовлетворять будущее изделие (в отечественной терминологии – известен «облик» будущего изделия). Во всяком случае, известно,
к какому классу изделий относится это будущее изделие (самолет, вертолет, автомобиль, танк, подводная лодка и т. п.). Как правило, известен также некоторый
подкласс (истребитель, транспортный самолет, грузовой или штурмовой вертолет
и т. д.).
В этой ситуации работа по созданию нового изделия начинается в службе УК
заказчика, в задачи которой на начальной стадии проекта входит:
• формирование (на основе «облика») первоначальной функциональной
структуры будущего изделия (аналог КИ) и уточнение требований;
• декомпозиция структуры на основные функциональные компоненты и соответствующая декомпозиция требований (выделение ОК верхнего уровня);
• выработка условий и подбор возможных участников тендера на разработку
и поставку изделия;
• согласование и уточнение с победителем тендера требований к изделию
в целом и к основным его функциональным компонентам (КИ, ОК).
После заключения контракта и начала работы над проектом служба УК заказчика взаимодействует со службой УК поставщика (разработчика) в решении следующих задач:
• в процессе проектирования запрашивает, получает и анализирует данные
и документы, подтверждающие (объективно доказывающие) выполнение требований к изделию и к его основным компонентам (ОК);
• на основе анализа выявляет те ОК, по которым требования не выполнены
или выполнены не в полном объеме;
• инициирует внесение разработчиком изменений в конструкцию соответствующих компонентов и проверяет результаты этих изменений;
• при необходимости и (или) возможности согласует разрешения на отклонения и сроки (условия) их действия;
• выполняет аналогичные операции на стадиях выпуска опытных образцов,
установочных серий (если таковые предусмотрены), а также в ходе серийного производства и на последующих стадиях ЖЦ (т. е. в ходе использования изделий
по назначению);
166
• сообщает поставщику (разработчику) все сведения о несоответствии требованиям (в том числе по конкретным экземплярам).
В рассматриваемой ситуации служба УК поставщика (разработчика) должна
в опережающем режиме (по отношению к службе УК заказчика) проводить перечисленные выше действия, а также более глубоко декомпозировать требования,
формируя ОК более низкого уровня, и выполнять описанные выше процедуры по
отношению к ним. Кроме того, служба УК поставщика должна выполнять операции, описанные в предыдущих ситуациях.
По завершении проекта ситуация сведется к одной из рассмотренных выше.
4. Создание нового изделия по инициативе поставщика. Базового изделия нет.
Исходные требования к новому изделию и его «облик» формируются на основе
маркетинговых исследований, анализа состояния, тенденций и прогноза развития
данного вида техники и т. д. Справедливы все исходные предпосылки ситуации 3
(относительно класса, подкласса и т. д.). Различие состоит лишь в том, что все
предпроектные и другие описанные выше функции выполняет служба УК предприятия (разработчика), включая, быть может, подготовку и проведение тендера
на поставку некоторых (основных) функциональных компонентов.
Кроме того, даже при создании принципиально нового изделия предприятие
стремится использовать имеющийся конструкторский и технологический задел,
что должно найти отражение при формировании новой (базовой) конфигурации.
При успешном завершении проекта ситуация сводится к 1-й или 2-й.
4.3.4. ТЕОРЕТИЧЕСКИЕ АСПЕКТЫ ПРОБЛЕМЫ УПРАВЛЕНИЯ КОНФИГУРАЦИЕЙ
Структурные отношения и их представление. Ранее использовались понятия (объекты и отношения), к числу которых относится понятие структуры изделия, определяемое как множество компонентов (элементов), связанных отношениями входимости. В конструкторском контексте структура отражает состав изделия в терминах естественной иерархии: изделие – система – узел – подузел –
деталь. (Узлы и подузлы иногда объединяются общим понятием – сборочная единица.) Это означает, что изделие состоит из систем, системы – из узлов, узлы –
из подузлов, подузлы – из деталей.
При этом не исключается прямая входимость элементов низших уровней непосредственно в состав элементов высших уровней. Например, некоторые детали
могут входить непосредственно в изделие или узел и т. д.
Любая структура может быть представлена графом, вершины которого соответствуют элементам, а ребра – отношениям. В рассматриваемом контексте эти
элементы – суть «блоки» требований (в функциональной структуре) или конструктивные исполнения компонентов изделия (в проектной и последующих структурах). Отношения могут быть отношениями классификации (рис. 4.14–4.17) или отношениями входимости.
Далее будем рассматривать описание изделия в форме графа проектной
структуры.
Пусть изделие А <состоит из> элементов wk(k = 1...N), т. е. рассматривается
отношение входимости. Тогда
167
WA = { wk } ( k = 1,..., N),
(4.1)
где WA – полное (конечное и счетное) множество элементов изделия, N – мощность
множества, т. е. общее число входящих элементов.
Справедливо и обратное утверждение: элементы wk (k = 1,..., N) <входят в>
изделие А, wk ∈ WA(k = 1,..., N).
Пусть далее в составе изделия выделено I частей (системы, узлы, сборочные
единицы и т. п.). Каждая часть имеет свое множество элементов:
Wi =
{w }
qi
(qi = 1,..., Qi, i = 1,..., I ).
(4.2)
Заметим, что в частном случае Qi =1. Это означает неделимость i-й части либо
прямую входимость детали в конечное изделие. Очевидно, что
∑ Qi
= N.
i
Легко видеть, что каждое множество Wi есть подмножество множества WА, а
последнее есть объединение всех своих подмножеств:
I
∪W .
WA =
i
(4.3)
i =1
В свою очередь, выделенная часть может также быть разделена на части более
низкого (в смысле принятой иерархии) уровня, т. е. на подмножества
Wij ( j = 1,..., J ) , так что справедливо выражение
Wi =
J
∪W
ij
.
(4.4)
j =1
Число уровней разделения на части всегда конечно и определяется контекстом (см. выше).
Из (4.3) и (4.4) следует, что если
wk ∈ Wij , то wk ∈ Wi и wk ∈ WA .
С другой стороны:
 J

WA = ∪  ∪Wi  .
i =1  j =1

I
Любое подмножество Wi , Wij , ... (∀ i, j ,...) можно рассматривать как объект
конфигурации. Описанная ситуация отображается древовидным графом (рис. 4.20).
Как уже отмечалось, степень подробности отображения структуры изделия
или требований к нему в соответствующем графе определяется контекстом. В любом случае граф строится до уровня, на котором входящие элементы полагаются
неделимыми.
168
Рис. 4.20. Древовидный граф структуры
Выше мы рассматривали графовое представление требований к изделию (рис.
4.16–4.19). Здесь же необходимо отметить, что между графом требований и конструкторским графом, несмотря на некоторое внешнее сходство, имеются существенные смысловые различия. Граф требований, отображающий, по сути, отношения классификации, изначально определяет множественность вариантов конфигурации, которые могут формироваться выделением путей на этом графе, как
описано в подразд. 4.3.2.
Иными словами, между вершинами, относящимися к уровням ниже первого,
должны существовать отношения типа «ИЛИ», которые явно на графе не указаны
и подразумеваются по умолчанию. В конструкторском графе вариантность отдельных вершин должна быть специально оговорена правилами применяемости, определяющими условия единственности отношений входимости (по датам выпуска,
серийным номерам конкретных изделий, номерам партий и т. д.).
Пусть для некоторого OK Wk, находящегося на «предпоследнем» уровне графа требований, имеет место ситуация, показанная на рис. 4.21.
Рис. 4.21. Фрагмент графа требований
169
Элементы wks (s = 1, 2, ..., n) полагаются неделимыми. Однако для каждого
из них возможны различные версии, обладающие отличными друг от друга свойствами, т. е.
{w
= {w
, wk21 ,..., wkl 1 ,...wkL1} ,
wk 1 =
1
k1
wk 2
1
k2
, wk22 ,..., wkq2 ,...wkQ2 } ,
...................................................
wkn =
{w
1
kn
(4.5)
V
, wkn2 ,..., wknv ,...wkn
}.
Если никаких ограничений на выбор версий элементов не накладывается,
то число вариантов конфигурации OK Wk
М = L·Q· ... ·V.
(4.6)
Соответственно будет возрастать число версий на каждом следующем уровне,
в результате чего их общее число может стать чрезмерно большим. На практике,
однако, имеют место два обстоятельства, существенно ограничивающие число вариантов:
1. Число возможных (реально существующих) версий большинства элементов
невелико, а для многих – равно единице.
2. Существуют эмпирические правила, согласно которым выбор версии элемента wks допускает применение лишь вполне определенных версий элементов из
других «наборов». Такие правила естественно назвать правилами совместимости.
Формулирование и соблюдение этих правил – один из важнейших аспектов управления конфигурацией.
Пусть, например, узел Wk имеет 3 элемента. Каждый из элементов имеет несколько версий соответственно:
Первый элемент: w1k 1 , wk21 , wk31
– 3 версии.
Второй элемент: w1k 2 , wk22 , wk32 , wk42
1
k3
– 4 версии.
2
k3
Третий элемент: w , w
–2 версии.
Число возможных комбинаций элементов
М = 3·4·2 = 24.
Предположим, что существуют следующие правила совместимости:
если w1k 1 , то wk22 и wk23 ;
если wk21 , то wk32 и w1k 3 ;
если wk31 , то ( w1k 2 или wk42 ) и w1k 3 .
Эти правила допускают существование всего четырех вариантов узла Wk, т. е.
четыре его конфигурации.
170
В этой связи проблема выработки правил – «фильтров» представляется весьма
важной. В содержательном смысле эта проблема – чисто конструкторская, поскольку именно конструктор – разработчик изделия может обоснованно назначать
такие правила. С точки зрения информационных технологий здесь возникают две
задачи:
создание базы данных, содержащей описания конструктивных элементов
со всеми атрибутами (свойствами, характеристиками) и ссылки на соответствующую техническую документацию; здесь же могут храниться и полные описания
уже созданных изделий как ОК высшего уровня;
создание базы знаний, содержащей правила совместимости, например, в форме готовых таблиц возможных (допустимых) решений или матриц совместимости.
Что касается базы данных, то для ее создания в системе PSS имеется готовый
механизм категорий, с помощью которого, в частности, можно отображать все отношения классификации. Создание базы знаний может потребовать специальных
программных решений, например средств класса экспертных систем.
Матричное представление структурных графов. Как известно, любой граф
может быть представлен в матричной форме по крайней мере одним из двух способов: в форме матрицы инцидентности либо в форме матрицы смежности вершин, причем последний способ является более экономичным по сравнению с первым. Для неориентированного древовидного графа (дерева) матрица смежности –
симметрическая (n × n)-матрица, где n – общее число вершин, т. е. в нашем случае – число рассматриваемых элементов конструкции. Если рассматривать только
верхний уровень декомпозиции изделия, например граф, составленный только
из элементов W и Wi (см. рис. 4.20), то такой граф, как уже упоминалось, принято
называть звездным.
Для звездного графа матрица смежности будет иметь вид

W W1

W 0 1
W 1 0
1
M = 
 W2 1 0

 ... ... ...
W 1 0
 I
... WI 

1 ... 1 
0 ... 0  .

0 ... 0 

... ... ... 
0 ... 0 
W2
(4.7)
Размерность этой матрицы
n1 = 1 + n (n = I).
(4.8)
Если далее элементы 1-го уровня подвергаются декомпозиции и при этом каждый i-й элемент разбивается на mi(2) элементов 2-го уровня, то это означает, что
вследствие каждого такого разбиения размерность матрицы М увеличивается на
(mi(2) – l) строк и столбцов и становится равной
171
n2 = n1 +
n1 −1
∑(m
2
i
i =1
− 1) .
(4.9)
Если при этом какой-либо i-й элемент 1-го уровня не подвергается разбиению,
то это означает, что mi (2)= 1 и соответствующее слагаемое в (4.9) равно нулю.
Продолжая приведенные выше рассуждения, можно получить общую формулу для определения размерности матрицы М при k (k > 2) уровнях разбиения:
nk =
k −1
nj −1
∑ ∑(m
j =1
i =1
j −1
i
− 1) .
(4.10)
Пусть, например, структура изделия описывается графом, представленным
на рис. 4.22. Вершины графа для простоты перенумерованы.
Матрица смежности для вершин 0–1–2 будет
иметь вид
0 1 1 


M1 =  1 0 0  ,
1 0 0 


(4.11)
где единицы обозначают наличие связи между соответствующими вершинами.
Матрица М2 смежности для вершин 1–3–4 будет по виду совпадать с (4.11),
а матрица М3 смежности для вершин 2–5–6–7 будет иметь вид
Рис. 4.22. Пример древовидного графа
0

1
M3 = 
1

1
1 1 1

0 0 0
.
0 0 0

0 0 0
(4.12)
Чтобы построить полную матрицу для графа по рис. 4.20, поступим следующим образом. Сначала совместим верхний левый угловой элемент матрицы М2 со
второй ячейкой главной диагонали матрицы Ml, т. е. с ячейкой, соответствующей
вершине 1, и вставим М2 в Ml. В результате получим новую матрицу следующего
вида:
0

1
M1 − 1 = 
0

1
172
1

0 1 1 0
.
1 0 0 0

0 0 0 0
1
0
0
(4.13)
Здесь рамкой обозначена матрица М2, «внедренная» в матрицу Ml. Размер
матрицы М1–1 равен размеру матрицы М1+ размер матрицы М2–1, т. е. (5×5).
матрице М1–1 вершине 2 соответствуют последний столбец и последняя строка.
Чтобы получить полную матрицу графа, нужно к М1–1 присоединить матрицу М3,
совместив ее верхний левый угол с правым нижним углом матрицы М1–1. Тогда
получим
0

1
0

0
M = 1

0
0

0


1 0 0 1 0 0 0

0 1 1 0 0 0 0
1 0 0 0 0 0 0

1 0 0 0 0 0 0
0 0 0 0 1 1 1 .

0 0 0 1 0 0 0
0 0 0 1 0 0 0

0 0 0 1 0 0 0


(4.14)
В матрице М выделены блоки, соответствующие М2 и М3, а общий размер
матрицы согласно (4.10) равен (8×8).
Выше предполагалось, что каждая вершина графа, отображаемого матрицей
смежности, соответствует конструктивному элементу, имеющему единственную
версию. Если элементы (вершины графа) могут существовать в нескольких версиях, то этот факт может быть отражен в матрице смежности заменой любого ее ненулевого элемента целым числом, равным количеству таких версий.
Пусть, например, в графе на рис. 4.22 элемент 4 имеет две версии, а элемент
6 – три версии. В матрице (4.14) этот факт отобразится следующим образом.
0

1
0

0
M = 
1

0
0

0
1 0 0 1 0 0 0 

0 1 2 0 0 0 0 
1 0 0 0 0 0 0 

2 0 0 0 0 0 0 .
0 0 0 0 1 3 1 

0 0 0 1 0 0 0 
0 0 0 3 0 0 0 

0 0 0 1 0 0 0 
(4.15)
Иными словами, наличие в матрице смежности ячеек со значением, превосходящим единицу, является признаком множественности структур изделия, описываемого соответствующим графом.
173
4.3.5. МЕТОДИКА СИНТЕЗА КОНФИГУРАЦИЙ
Базируясь на описанных представлениях, рассмотрим упрощенную методику
формального синтеза конфигураций изделия. Основное упрощение состоит в том,
что мы не будем учитывать условия совместимости элементов конструкции.
В качестве исходного материала для синтеза будем рассматривать звездный
граф функциональной структуры (функциональной конфигурации), подобный рис.
4.16. Будем в соответствии с содержанием подразд. 4.3.2 трактовать этот граф как граф
требований к будущему изделию.
Предположим далее, что общие требования к изделию образуют многомерный
вектор Rt. Упорядочив компоненты этого вектора, разобьем их на группы так, чтобы
каждая группа соответствовала вершине функционального графа:
Rt = [(r1, r2,…, rk1), (rk1+l, rk1+2,..., rk2), … (rk(n-1)+l, rk(n-1)+2,..., rkn)]. (4.16)
Каждую группу компонентов будем рассматривать как отдельный вектор:
Rt1 = (r1, r2,…, rk1),
Rt = (rk1+l, rk1+2,..., rk2),
…………………………..
Rtn = (rk(n-1)+l, rk(n-1)+2,..., rkn),
(4.17)
где п – число элементов в структуре графа требований.
Любому из компонентов векторов (4.17) может быть назначен допуск
δi ( i = 1,..., kn ) . Полагая все компоненты векторов нормированными, будем считать, что геометрическая сумма допусков δi определяет в соответствующем векторном пространстве вектор ∆ j . Если в таком векторном пространстве построить
вокруг точки, задаваемой концом вектора Rtj, сферу радиуса ∆ j , то эта сфера определит область допустимых значений характеристик конструктивного элемента
(рис. 4.23).
Предположим, что для каждого j-го элемента функциональной структуры имеется
Мj конструктивных реализаций (версий), информация о которых в виде структурных
графов хранится в PDM-системе (в долговременном разделе общей базы данных об изделиях). Каждая реализация обладает собственным набором Mj характеристик, представляемым в виде вектора той же размерности,
что и соответствующий вектор Rtj. Компоненты вектора Mj характеристик имеют ту же
Рис. 4.23. Векторы требований, характеристик физическую природу, что и компоненты веки область допустимых значений
тора Rtj, т. е. эти векторы принадлежат одному и тому же пространству.
174
Иными словами, векторы характеристик имеют вид
(
= (м
)
M1i = м1i , мi2 ,..., мik1 ,
M i2
i
k1 +1
)
, м ik1 + 2 ,..., мik2 ,
(i
...........................................
(
)
= 1,..., m j , j = 1,..., n )
(4.18)
M in = мik( n−1) +1 , мik( n−1) + 2 ,..., мikn .
Вычислим модули разностей векторов требований и характеристик:
e1i =
ei2 =
k1
∑(r
j =1
− мij ) ,
2
j
k2
∑ (r
j = k1 +1
− мij ) ,
2
j
(i = 1,..., m j , j = 1,..., n)
(4,19)
......................................
ein =
kn
∑ (r
j = k( n−1) +1
− мij ) .
2
j
Выберем из каждого набора величин eij минимальную, т. е. получим:
e1s1 → min {e1i }
i = (1,..., m1 ),
e 2s2 → min {ei2 }
i = (1,..., m2 ),
(4.20)
....................................................
e nsn → min {ein }
i = (1,..., mn ).
Номера s1, s2,…, sn показывают, какие из вариантов конструктивных реализаций
компонентов должны рассматриваться в качестве «кандидатов» на включение в проектную конфигурацию изделия. Для принятия окончательного решения следует проверить условие
s
e jj ≤
j
(j
= 1,..., mn ) .
(4.21)
Выполнение этого условия графически представлено на рис. 4.23, где видно,
что точка, определяемая концом вектора характеристик Mj, попадает в ∆ j – окрестность точки, определяемой концом вектора Rtj. Те конструктивные реализации элементов, для которых условия (4.21) выполнены, могут быть включены в структуру
проектируемого изделия (проектную конфигурацию).
Те элементы, для которых условие (4.21) не выполняется, требуют принятия
одного из трех решений:
175
• необходимо в соответствующем классе элементов искать такую конструктивную реализацию (быть может, ранее не применявшуюся на данном предприятии),
для которой условие вида (4.21) будет выполнено; при положительном результате поиска найденное решение может быть включено в состав проектной конфигурации;
• при отрицательном результате поиска или если использование найденного
решения будет по каким-либо соображениям признано нецелесообразным, следует
предпринять попытку внесения конструктивных изменений в один из имеющихся
в базе данных вариантов реализации элемента с тем, чтобы обеспечить выполнение
условия (4.21). В этом случае элемент подлежит декомпозиции, в соответствии
с которой должен быть детализирован и вектор требований к элементу;
• может оказаться более рациональным создание новой конструктивной реализации элемента, не имеющей ранее использовавшегося прототипа. В этом случае
также требуется декомпозиция элемента и детализация вектора требований, на основе которой может быть сформулировано техническое задание на проектирование.
После внесения изменений в имеющуюся конструкцию или по завершении
проектирования нового конструктивного варианта разработчик обязан предоставить
объективные доказательства того, что для нового или измененного варианта конструкции условие (4.21) выполнено. Оценка этих доказательств есть функция менеджера по конфигурации. По завершении формирования проектной конфигурации
описанным выше способом последняя утверждается и приобретает статус ПБК.
Здесь необходимо сделать следующее замечание. В любом наборе конструктивных реализаций j-го элемента могут содержаться две или более таких, у которых
значения e окажутся равными. Это означает, что такие реализации являются полностью взаимозаменяемыми, и применение в изделии любой из них не порождает новой
конфигурации.
Описанная выше формальная процедура синтеза конфигурации завершается
тем, что из долговременного раздела общей базы данных об изделиях, в котором
описания конструктивных реализаций элементов хранятся в форме графов или соответствующих матриц, извлекаются описания с номерами (кодовыми обозначениями) s1, s2, ..., sn, и из них формируется общая матрица структуры изделия или соответствующий граф.
4.4. ОСОБЕННОСТИ СИСТЕМЫ УПРАВЛЕНИЯ ПРОЕКТАМИ
Под управлением проектами подразумевают деятельность, направленную наорганизацию, планирование и контроль выполнения проектов.
Часто управление крупными проектами, включающее распределение большого числа работ во времени и между исполнителями, выполняется программами,
относящимися к специальной группе систем управления проектами. В эту группу
входят программы верхнего уровня, такие как Artemis Project (фирма Metier),
Primavera Project Planner (Primavera Systems), Open Plan (Welcom Software), среднего уровня – Time-Line (Symantec), Microsoft Project (Microsoft) и др.
Например, система Project Manager Workbench служит для одновременного
управления различными проектами с оптимальным распределением ресурсов, помогает построить иерархическую структуру плана, сформировать несколько видов
176
отчетов, описывающих расписания, расходы, контроль качества. С ее помощью
контролируют общее использование ресурсов, составляют расписания разнохарактерных работ. В качестве ресурсов могут рассматриваться люди, финансовые средства, устройства.
Управление проектами (процессом проектирования) входит также в число
функций PDM. Проектирование состоит из многих шагов, объединяемых в потоки
работ (workflow). Управление потоком работ включает в себя большое число действий и условий, поддерживающих параллельную работу многих пользователей
над общим проектом. Необходимо распределить работы как между исполнителями, так и во времени, а также обеспечить контроль выполнения работ.
Шаги заданного или динамически определяемого маршрута работ могут представлять собой выполнение проектных операций и процедур, пересылку документов и файлов другим пользователям, изменение статуса объекта, просмотр, контроль и утверждение инженерных проектов и внесения в них изменений и т.п. Между шагами перемещается пакет документов. На шагах маршрута документы
проекта обрабатываются, видоизменяются, оцениваются, пакет автоматически пополняется, и в конечном счете проектная документация выпускается в производство.
Системы workflow должны автоматически генерировать предупреждения
в случае замедления процесса и указывать место, где он застопорился или замедлился; отражать состояние процесса; предоставлять статистику по процедурам
и функциям.
Управление потоком работ выполняется на основе моделей вычислительных
процессов. Используются спецификации моделей, принятые в CASE-системах, например диаграммы потоков данных, ориентированные графы, UML-диаграммы.
Сначала модели составляют в терминах проектных заданий, а затем система
осуществляет их покрытие имеющимися проектирующими программами и программными модулями. Применяют также описания на языках расширения или 4GL.
Особенностями системы управления проектами можно определить следующее:
• изначальная ориентация на параллельное ведение проекта в электронном
виде и на бумаге;
• возможность постановки подписи ВКК (ведущим по контракту) как удостоверяющей подпись должностного лица, проставленную на бумаге;
• список основных работ по контракту, включаемый в перечень работ, фиксирован и является шаблоном документа;
• если перечень работ или план-график подписал начальник более высокого
ранга, то подпись нижестоящих должностных лиц не обязательна и документ считается утвержденным;
• возможность временной передачи права подписи другому лицу.
Подходы к управлению проектами в классическом варианте и при использовании PDM можно представить в виде табл. 4.2. На рис. 4.24 в качестве примера
представлена последовательность и взаимодействие процедур выполнения контракта по разработке конструкторской документации, на рис. 4.25 – алгоритм процедуры планирования и контроля выполнения контракта по УГК, на рис. 4.26 –
схема процедуры планирования контракта.
177
Таблица 4.2
ПОДХОДЫ К УПРАВЛЕНИЮ ПРОЕКТАМИ
№
п/п
Этапы
Классическая система
PDM
1 Структура проекта
Описывается до начала выполнения
проекта
На момент начала
выполнения проекта может
быть неизвестна
2 Длительность проекта
Сумма длительностей входящих
в него работ
Назначается директивно
3 Пересмотр сроков
Изменение длительности работ
приводит к изменению длительности
проекта
Изменение длительности
работ не отражается
на длительности проекта
4 Управление
ресурсами
Длительность работ зависит от
загруженности ресурсов
Загруженность ресурсов
не рассматривается
5 Рабочие объекты
Не рассматриваются
Любая информация
Рис. 4.24. Последовательность и взаимодействие процедур выполнения контракта
по разработке конструкторской документации
178
Рис. 4.25. Алгоритм процедуры планирования и контроля выполнения контракта по УГК
(см. также с. 180)
179
Рис. 4.25. Окончание
180
1. Отв.: секретарь ГК
Регистрирует поступившую информацию в соответствии с действующими
правилами делопроизводства и передает ее ГК. Информация может включать: контракт, заказ-уведомление, распоряжение руководства и т.п. Устная информация
документируется.
2. Отв.: ГК
Принимает решение об открытии проекта. Издает распоряжение о назначении
ведущего конструктора по контракту. Указывает сроки подготовки план-графиков,
если они отличаются от стандартных, и привлекаемые отделы.
Срок: 1 раб. день от поступления информации.
3. Отв.: ГК
Распоряжение доводится до сведения ВКК под подпись. Передаются сопутствующие документы.
4. Отв.: ВКК
Разрабатывает проект Перечня работ УГК по контракту, обеспечивающих
контракт по технической службе по форме Ф-К2. При необходимости привлекает руководителей служб и специалистов. «Привязывает» Перечень работ к срокам выполнения контракта.
5. Отв.: ГК
Согласовывает проект Перечня работ и направляет главному инженеру. В противном случае возвращает на доработку.
6. Отв.: ВКК
Дорабатывает проект Перечня работ и вновь передает на согласование и утверждение.
7. Отв.: ГИ
Утверждает Перечень работ и направляет ГК для исполнения. В противном
случае возвращает на доработку.
Срок: 3 раб. дня от указания о начале работы.
8. Огв.: ГК
Задание доводится до ВКК под подпись. Копия передается в Б ТУ СЗ для заполнения «экрана». Отчет о ходе работ в объеме «экрана» возлагается на ответственного сотрудника БТУ СЗ.
9. Задание доводится до начальников отделов под подпись. При необходимости
проводится совещание.
Срок: 1 раб. день от утверждения план-графика.
10. Прорабатывают вместе с начальниками бригад предложения в Перечень
работ, при необходимости привлекают ВКК. Предложения готовятся по форме
Ф-КЗ. Предложения передаются ВКК.
Срок: 5 раб. дней от получения задания.
11. Составляет проект План-графика работ по УГК по форме Ф-КЗ и передает
на согласование и утверждение.
12. Отв.: начальники отделов УГК
Согласовывают предложения или возвращают на доработку.
13. Отв.: ВКК
181
Дорабатывает проект План-графика по УГК и вновь передает на согласование
и утверждение. В случае категорического несогласия обращается к руководству
УКГ.
14. Отв.: ЗГК
Согласовывает План-график или возвращает на доработку.
15. Отв.: ВКК
Дорабатывает проект План-графика по УГК и вновь передает на согласование
и утверждение.
16. Отв.: ГК
Утверждает План-график и передает в Б ТУ СЗ. В противном случае возвращает на доработку.
Срок: 4 раб. дня от получения предложений от отделов.
17. Отв.: начальник Б ТУ СЗ
План-график и Перечень работ архивируются в Б ТУ СЗ.
18. Отв.: ВКК
Доводит План-график до начальников отделов под подпись для исполнения.
Срок: 1 раб. день от утверждения план-графика.
19. Отв.: начальники отделов
Контролирование выполнения заданий, доведение информации до начальников отделов и ВКК на еженедельных совещаниях в соответствии с Процедурой контроля хода выполнения контракта по УГК.
Рис. 4.26. Схема процедуры планирования контракта
182
4.5. КОНТРОЛЬНЫЕ ВОПРОСЫ
1. Дать определение системы управления данными об изделии и информационными процессами (Product Data Management – PDM).
2. Задачи, решаемые с помощью PDM-технологии.
3. Охарактеризовать информационные связи разработчиков с зонами базы
данных.
4. Этапы внедрения PDM-системы.
5. Конструкторская и технологическая спецификации изделия в PDM-системе.
6. Интеграция данных об изделии.
7. Проблема автоматизации управления конфигурацией промышленных изделий.
8. Дать схему управления конфигурацией.
9. Контексты управления конфигурацией.
10. Дать сценарий управления конфигурацией.
11. Особенности системы управления проектами.
183
5. ИНТЕГРИРОВАННАЯ ЛОГИСТИЧЕСКАЯ ПОДДЕРЖКА
5.1. АКТУАЛЬНОСТЬ ПРОБЛЕМЫ ПОВЫШЕНИЯ КАЧЕСТВА ПРОДУКЦИИ
Как уже было отмечено ранее, основной смысл ИПИ-технологии заключается
в повышении конкурентоспособности продукции за счет эффективного управления
информационными ресурсами. Это достигается благодаря преобразованию жизненного цикла изделия в высокоавтоматизированный процесс, интегрированный
с точки зрения информационного взаимодействия между заводами-изготовителями
и предприятиями-поставщиками комплектующих изделий по вопросам заказа запасных частей, расходных материалов и т. д.
Важной методологической основой построения подобного рода систем являются принципы и идеи менеджмента качества, заложенные в блоке международных стандартов ISO 9000:2000.
Фактически в настоящее время России необходима «Индустрия менеджмента
качества» и «Индустрия ИПИ-технологий», обслуживающая все сферы экономики
и обеспечивающая консультационные, инновационные, информационные и образовательные услуги. Необходимо разработать концепцию, в которой следует определить и обосновать основные направления и первоочередные задачи в области
обеспечения качества продукции промышленных предприятий (далее – качества
продукции), которые необходимо решать программными методами с учетом приоритетов и целей развития промышленности, а также целей структурной, промышленной и научно-технической политики.
Для решения задач обеспечения качества необходимо применять различную
тактику управления качеством, или, как чаще называют, контроль качества (Quality
Control, QL). Качество продукции часто определяет долгосрочную стратегическую
линию производства.
Движущей силой развития промышленности в условиях рыночной экономики
является стремление предприятий повысить качество и конкурентоспособность
выпускаемой продукции как обязательного условия ее реализации на рынке. Основу обеспечения качества можно кратко сформулировать так: потребитель должен
покупать только годные изделия; основные усилия должны быть направлены на то,
чтобы негодные изделия (брак) были бы отсечены от потребителя.
Качество продукции является важнейшим фактором, определяющим уровень
эффективности производства и стоимости продукции. Повышение качества
не только обеспечивает снижение затрат на устранение дефектов в процессе производства и эксплуатации продукции в общей стоимости затрат на ее производство
и эксплуатацию, но и увеличивает деловую и инвестиционную привлекательность
предприятия.
Система менеджмента качества (далее – СМК), отвечающая требованиям
международных стандартов ISO серии 9000, является не только эффективным способом повышения качества продукции и эффективности производства, но и практически обязательным условием получения предприятием государственных заказов и выгодных контрактов.
184
В последнее десятилетие важной составляющей обеспечения качества наукоемкой продукции стали новейшие технологии информационного обеспечения качества продукции. В настоящее время в связи с введением новых стандартов ISO
серии 9000 версии 2000 обязательной и важнейшей составляющей СМК должна
стать интегрированная информационная система анализа и управления информационными и материальными потоками в процессах управления качеством продукции на всех этапах жизненного цикла. Разработка и введение стандартов ISO
9000:2000 объясняется тем, что на ведущих зарубежных фирмах основой современных СМК стало применение принципов «всеобщего менеджмента качества»
(Total Quality Management, TQM), процессного подхода при решении вопросов организации и управления производством и социально ориентированных методов
руководства предприятием. Для реализации указанных подходов применяются
компьютерные технологии менеджмента качества (далее – КМК-технологии).
Указанные технологии решают задачи анализа существующих на предприятии информационных и материальных потоков в процессах организации и управления
производством. При этом важной составляющей КМК-технологий является создание компьютерной системы ведения электронного паспорта каждого изделия и его
составляющих.
К ключевым областям менеджмента качества и ИПИ-технологий относят:
• реорганизацию производственной деятельности;
• построение систем менеджмента качества;
• электронный документооборот и обмен данными;
• интегрированную логистическую поддержку;
• параллельное проектирование и многопользовательские базы данных;
• международные и отечественные стандарты в сфере менеджмента качества
и ИПИ-технологий.
Поэтому главной целью развития и внедрения менеджмента качества и ИПИтехнологий является повышение конкурентоспособности продукции благодаря рациональной организации и сокращению затрат и сроков на освоение и вывод продукции на рынок на базе системной интеграции.
Достигается поставленная цель, в основном, за счет:
• организации процессов на принципах и технологиях менеджмента качества;
• использования преимуществ корпоративного разделения труда и стандартизации;
• использования преимуществ технологии параллельных процессов, когда
создание изделия осуществляется одновременно несколькими участниками производства;
• создания единого информационного пространства, что устраняет информационные барьеры между этапами жизненного цикла изделий и минимизирует возникающие ошибки.
Иностранные заказчики отечественной продукции (Индия, Китай, Южная Корея) выдвигают требования, удовлетворение которых невозможно без внедрения
ИПИ-технологий:
• представление конструкторской и технологической документации в электронной форме;
185
• представление эксплуатационной и ремонтной документации в форме интерактивных электронных технических руководств (ИЭТР), снабженных иллюстрированными электронными каталогами запасных частей и вспомогательных материалов и средствами дистанционного заказа запасных частей и материалов;
• организация интегрированной логистической поддержки изделий в процессе
эксплуатации;
• наличие и функционирование электронной системы каталогизации продукции;
• наличие на предприятиях соответствующих требованиям стандартов ISO
9000:2000 компьютерных систем менеджмента качества и т.д.
Выполнение этих требований предопределяет необходимость внедрения
ИПИ-технологий на отечественных предприятиях-экспортерах.
Приведенный анализ показывает, что проблема обеспечения качества продукции предприятий стала национальной проблемой, от решения которой во многом
зависит обороноспособность и экономическая независимость страны. Повышение
качества – сложная и многогранная проблема, для ее решения требуются усилия
федеральных органов исполнительной власти совместно с предприятиями.
5.2. СТАНДАРТЫ УПРАВЛЕНИЯ КАЧЕСТВОМ
Международная организация по стандартизации (ИСО) основана 23 февраля 1947 г. пятнадцатью национальными организациями по стандартизации,
осуществляет деятельность, направленную на содействие развитию стандартизации в мировом масштабе для облегчения товарообмена и взаимопомощи,
а также для расширения сотрудничества в области интеллектуальной, научной, технической и экономической деятельности. Около 2500 рабочих органов
ИСО (технических комитетов, подкомитетов, рабочих групп), в деятельности
которых принимают участие более 50 тыс. специалистов разных стран, занимаются разработкой международных стандартов, которые носят рекомендательный характер, однако на практике соблюдаются странами.
Необходимо указать международные частные организации, являющиеся лидерами среди классификационных и сертификационных организаций.
Регистр Ллойда (Lloyd's Register) – международная неправительственная
независимая корпорация, основанная в 1760 г. и реорганизованная в 1884 г.,
является в течение двух столетий мировым лидером среди классификационных
и сертификационных организаций.
ТЮФ-Серт (TUV Sert) – организация, образованная всеми обществами
технического надзора Германии в 1989 г.
Норвежская фирма Дет Норске Веритас – ДНВ (Det Norske Veritas –
DNV) – одна из старейших сертификационных организаций, имеющая более чем
столетний опыт работы (создана в 1864 г.).
СЖС (Societe Generate de Surveillance – SGS) – крупнейшая независимая международная организация по инспектированию, испытаниям и контролю. Основана в 1878 г.
186
Инчкейп (Inchcape Testing Services) – ведущая корпорация, объединяющая
многие старейшие компании, занимающиеся независимыми испытаниями,
инспектированием и сертификацией.
ИСО издает кроме международных стандартов ряд различных материалов,
среди которых руководства по наиболее актуальным темам международной
стандартизации (совместно с МЭК – международной электротехнической комиссей), непериодические справочные издания, такие как «Сертификация.
Принципы и практика», «Знаки соответствия стандартам» и др.
На ежегодных сессиях Генеральной ассамблеи ИСО принимается стратегический план организации.
Сессия Генеральной ассамблеи ИСО в Женеве в сентябре 1995 г. одобрила
принципы создания Международной системы признания (регистрации) оценки
систем качества в соответствии со стандартами ИСО серии 9000. Эти принципы
включают:
• открытость для всех органов по аккредитации во всем мире;
• равнозначную и независимую оценку органами по аккредитации систем
качества;
• единые критерии и процедуры оценки;
• финансовую независимость от других программ ИСО и МЭК;
• использование знака ИСО/МЭК, означающего мировое признание
СССР, а затем Россия как его правопреемник стала членом ИСО с правом голоса, избрания в Совет и участия в заседаниях Генеральной ассамблеи ИСО.
В соответствии с принятым в ИСО соглашением все страны-члены ИСО
обязуются высылать другим странам-членам экземпляры национальных стандартов. Таким образом, Россия как член ИСО располагает подборкой национальных стандартов всех стран-членов ИСО. С помощью автоматизированной
системы информации о стандартах (так называемой информационной сети
ИСОНЕТ) удовлетворяется спрос на информацию о стандартах, технических
регламентах и других подобных документах.
5.2.1. МЕЖДУНАРОДНЫЕ СТАНДАРТЫ
Основными причинами появления стандартов серии ISO 9000 были потребности в общем для всех участников международного рынка базисе для контроля
и управления качеством товаров. Американское общество контроля качества
(ASQC) определило цели стандартов серии ISO 9000 как помощь в развитии международного обмена товарами и услугами и в кооперации в сфере интеллектуальной, научной, технологической и деловой активности.
В стандартах серии ISO 9000 используется определение качества из стандарта
ISO 8402, в котором под качеством продукции подразумевается своевременное
удовлетворение требований заказчика по приемлемой цене. Вводится понятие системы качества (Quality System, QS) как документальной системы с руководствами
и описаниями процедур достижения качества. Другими словами, система качества
есть совокупность организационной структуры, ответственности, процедур, процессов и ресурсов, обеспечивающая осуществление общего руководства качеством.
187
Система качества обычно представляет собой совокупность организационной
структуры, методик, процессов и ресурсов, необходимых для осуществления общего руководства качеством, и содержит три вида документов:
• описание политики управления для каждого системного элемента (организация, ответственные, контроль);
• описание процедур управления качеством (что, где, кем и когда должно
быть сделано);
• тесты, планы, инструкции и т. п.
Серия стандартов ISO 9000 состоит из пяти групп документов:
• ISO 9000 − Управление качеством. Утверждение стандартного качества: Руководящие правила для выбора и использования стандартов ISO 9001, ISO 9002,
ISO 9003.
• ISO 9001 − Система качества: Модель для утверждения качества в проектировании, подготовке производства, производстве, внедрении и сервисе.
• ISO 9002 − Система качества: Модель для утверждения качества в производстве, внедрении и сервисе.
• ISO 9003 − Система качества: Модель для утверждения качества в конечном
контроле и тестировании.
• ISO 9004 − Управление качеством: Руководящие правила для применения
системы управления качеством компании и ее элементов.
Стандарт ИСО 9001 используется в том случае, когда соответствие определенным требованиям должно обеспечиваться поставщиком на определенных этапах, которые могут включать проектирование и (или) разработку, производство,
монтаж и обслуживание.
Стандарт ИСО 9002 используется в случае, когда соответствие определенным
требованиям должно обеспечиваться поставщиком в процессе производства и монтажа.
Стандарт ИСО 9003 используется в случае, когда соответствие определенным
требованиям должно обеспечиваться поставщиком только в процессе окончательного контроля и при испытаниях.
Стандарт ИСО 9004 содержит руководящие указания для организаций
и предприятий, которые не могут быть использованы ими в целях общего руководства качеством и элементами системы. Положения данного стандарта относятся
к техническим, административным и человеческим факторам, влияющим на качество продукции или услуг.
В стандарте ISO 9004 содержатся 20 основных требований к качеству, называемых системными элементами. Системные элементы разделены на группы, относящиеся к производству, транспортировке и постпроизводственным операциям,
документации продукции, маркетингу. Например, при производстве контролируются планирование, процедуры, программы и инструкции для управления и улучшения производственных процессов. При маркетинге контролируются такие системные элементы, как функциональное описание продукции, организация обратной связи с заказчиками (отслеживание и анализ рекламаций).
Поддерживающие стандарты предназначены для развития и установки систем
качества:
188
• ISO 10011 − аудит, критерии для аудита систем качества.
• ISO 10012 − метрологическое подтверждение качества.
• ISO 10013 − пособие для развития руководств по управлению качеством.
В настоящее время разработана новая версия стандартов серии ISO 9000
под названием ISO 9000:2000 Quality management systems (системы управления
качеством), в которую включены документы:
• ISO 9000:2000 Fundamentals and vocabulary (основы и терминология).
• ISO 9001:2000 Requirements (требования).
• ISO 9004:2000 Guidelines for performance improvement (руководство по развитию).
Главные отличия новой версии от предыдущей обусловлены стремлением упростить практическое использование стандартов, направлены на их лучшую гармонизацию.
В стандарте ISO 9001:2000 минимизируется объем требований к системе качества. Стандарты ISO 9002−9003 из новой версии исключаются. Расширяется
круг контролируемых ресурсов, в их число включены такие элементы, как информация, коммуникации, инфраструктура. Приведенные в стандарте ISO 9004 20 элементов качества в версии 2000 г. сворачиваются в четыре группы:
• распределение ответственности (management responsibility);
• управление ресурсами (resource management);
• реализация продукции и услуг (product and/or service realization);
• измерения и анализ (measurement, analysis, and improvement).
Стандарты серии ISO 14000 посвящены проблеме выполнения промышленными предприятиями экологических требований. По своей целевой направленности они близки к стандартам управления качеством промышленной продукции серии ISO 9000. Стандарты серии ISO 14000 являются также системой управления
влиянием на окружающую среду, они, как и стандарты серии ISO 9000, реализуются в процессе сертификации предприятий, задают процедуры управления и контроль документации, аудит, подразумевают соответствующее обучение и сбор статистики. Кроме требований заказчиков и покупателей в них воплощаются внутренние требования организации.
Две группы документов (ISO 9000, ISO 9004) являются руководствами и содержат руководящие инструктивные материалы. ISO 9000 − по выбору модели
для утверждения качества, ISO 9004 − по проектированию, внедрению и сертификации системы управления качеством компании.
Процедура сертификации включает четыре этапа:
1. Обследование фирмы. Заключается в обследовании и анализе фирмы с точки зрения качества ее продукции и сопутствующего сервиса, соответствующей
системы CQS; создании рабочей группы с участием представителя ISO; разработке
рабочего плана.
2. Проектирование системы управления качеством компании (CQS). Включает
следующие шаги: выбор стандарта документации и подготовку руководства
по системе CQS; проектирование новой системы CQS, отвечающей требованиям
ISO; детальное документирование новой системы CQS, в том числе учебник
189
качества, генеральные процедуры контроля, оперативные инструкции персоналу
и формы статистического контроля качества.
3. Развертывание системы. Предполагает работу с персоналом в плане сертификации, обучение новым процедурам и инструкциям, апробацию новой системы
CQS (в течение определенного времени), внешний и внутренний аудит, разработку
практических приложений системы.
4. Сертификация. Включает конечное обследование системы CQS, проводимое
внутренними аудиторами (персонал высшего менеджмента фирмы); инспекцию,
проводимую регистратором CQS по замечаниям регистратора; получение сертификата ISO 9000 и регистрацию компании в реестре сертификационных компаний.
Серия стандартов качества ISO 9000 и концепция всеобщего направления качеством TQM дополняют друг друга, имея общую цель − максимальное удовлетворение запросов потребителя через качество товара и сопутствующего сервиса.
Деятельность испытательных лабораторий, органов по сертификации продукции, систем качества и аттестации персонала, а также товаропроизводителей
при заявлении о соответствии продукции в странах – членах Европейского экономического сообщества (ЕЭС) и в странах Европейской ассоциации свободной торговли регламентируется европейскими стандартами EN серии 45000. Стандарты
разработаны СЕН/СЕНЭЛЕК и представляют собой организационно-методические
документы, учитывающие опыт работы ИСО и МЭК в области сертификации
и смежных видов деятельности.
5.2.2. СТАНДАРТЫ ИСО 9000 В РОССИЙСКОЙ СЕРТИФИКАЦИИ
В рыночных условиях решение проблемы качества в России во многом будет
зависеть от формирования системы стандартов качества как основы нормативноправовой базы организации и функционирования системы управления качеством.
С переходом к рынку изменился сам подход к организации и использованию
системы стандартов. Организация работ по стандартизации стала более демократичной, проводится на добровольной основе, а применение стандартов в большей
части носит рекомендательный характер. Однако требования государственных
стандартов РФ подлежат обязательному выполнению, если они связаны с безопасностью жизни и здоровья людей, их имущества, охраны окружающей среды и т. п.
Обязательными к применению на предприятиях и в организациях России являются
также требования стандартов, которые включены в договоры на производство
и поставку проектируемой продукции, и требования, предусмотренные законодательными актами Российской Федерации.
В Российской Федерации существуют следующие нормативные документы по
стандартизации:
• государственные стандарты РФ (ГОСТ);
• отраслевые стандарты (ОСТ);
• технические условия (ТУ);
• стандарты предприятий и объединений, ассоциаций, концернов;
• стандарты научно-технических обществ и инженерных союзов, ассоциаций
и других общественных организаций.
190
Создание в России системы стандартов, соответствующих требованиям рыночной экономики, позволяет:
• значительно расширить круг заказчиков и потенциальных пользователей
стандартов, существенно повысить заинтересованность и изменить мотивации их
разработки, усиливая внимание к проблеме снижения издержек производства;
• превратить стандарты в практический инструмент борьбы за рынок потребителей;
• стимулировать в интересах потребителей использование стандартов для усиления конкуренции между производителями за более высокие потребительские
свойства товаров;
• превратить стандарты в продукт демократического согласования заинтересованности участников, что позволяет избегать диктата и обеспечивает заинтересованность в применении и соблюдении требований стандартов;
• создать необходимые условия конкурентоспособности и успешной работы
на рынке.
Некоторые из стандартов серии ISO 9000 утверждены в качестве государственных стандартов Российской Федерации, в частности следующие:
• ГОСТ Р ИСО 9001-96 «Системы качества. Модель обеспечения качества
при проектировании, разработке, производстве, монтаже и обслуживании».
• ГОСТ Р ИСО 9002-96 «Системы качества. Модель обеспечения качества
при производстве, монтаже и обслуживании».
• ГОСТ Р ИСО 9003-96 «Системы качества. Модель обеспечения качества
при окончательном контроле и испытаниях».
Одной из важнейших причин тяжелого состояния российской экономики является крайне низкий уровень управления и организации труда.
Уже на протяжении более чем трех десятилетий в нашей стране постоянно
возрастают неоправданные потери материально-энергетических и трудовых ресурсов во всех без исключения отраслях промышленности.
Иностранных партнеров восхищает и даже настораживает глубина и наукоемкость наших разработок, но и одновременно удивляет рутина организации труда
и примитивная трактовка качества. Ранее имели место даже и такие мнения:
«Ни одна самая современная технология, опущенная в рутину советской организации труда и советского понимания качества, не даст ожидаемого результата и обречена на деградацию».
Отсутствие практики корректного и объективного учета потерь (издержек)
и их анализа с целью сокращения привело к расточительности, безответственности, разбазариванию природных богатств. Великая держава, занимающая первое
место по залежам полезных ископаемых, нерачительно растрачивая ограниченные
природные богатства и энергию, придет к невосполнимым потерям не только для
нее, но и для всего человечества.
Все потери (трудовые, материально-энергетические, а также потери комплектующих, элементной базы и т. д.) компенсируются предприятиями и организациями за счет увеличения себестоимости, что приводит к неоправданно высоким ценам на все виды товаров и услуг при крайне низком качестве и, как следствие,
191
к потере конкурентоспособности продукции, деградации производства и обнищанию масс. Так, на некоторых предприятиях от 30 до 70 % себестоимости составляют неоправданные внутрипроизводственные потери.
При внимательном и вдумчивом изучении стандартов ИСО 9000 становится
понятной главная идея методологии обеспечения качества, которая основана
на том, что понятие «улучшение качества» должно употребляться применительно
к любой сфере деятельности, поскольку качество продукции – следствие качественного выполнения всех видов работ. Качество – не абстрактная категория, а осязаемый каждым человеком конкретный измеритель полезности, целесообразности
и эффективности любого труда.
Повышение качества обязательно приводит к снижению издержек (потерь)
на всех этапах жизненного цикла продукции (разработка – производство – потребление), а следовательно, к снижению себестоимости, цены и повышению жизненного уровня людей.
Японский специалист К. Исикава писал, что безнравственно говорить о повышении цены при повышении качества продукции, т. к. повышение качества связано со стабилизацией производства, уменьшением дефектности, уменьшением
издержек, а следовательно, с уменьшением себестоимости и цены. К. Исикава писал также, что о повышении цены можно вести речь только тогда, когда потребитель получает продукцию принципиально нового технического уровня. Но и в этом
случае сразу необходимо планировать последующее снижение себестоимости
за счет отладки, стабилизации и доводки производственного процесса и упорядочения деятельности в цепи поставщик–изготовитель–потребитель. В этом залог экономического успеха фирмы, развития промышленности, состоятельности страны.
Как показывает зарубежная и отечественная практика, успех любой сферы
деятельности существенно зависит от умных и энергичных руководителей, которые хотят и умеют видеть в лице каждого сотрудника заинтересованного и активного партнера. Такие руководители четко понимают три золотые истины:
• первая – невежество стоит денег и очень дорого обходится;
• вторая – качество приносит деньги (т. к. связано с резким снижением издержек) и создает устойчивую экономическую стабильность и авторитет;
• третья: главное достояние – это люди, как внутри предприятия, так и за его
пределами. Именно поэтому в стандартах ИСО делается акцент на ответственность
руководителей, снижение издержек, кадровую политику.
5.3. ПОСТАНОВКА ЦЕЛЕЙ И ЗАДАЧ СИСТЕМЫ УПРАВЛЕНИЯ КАЧЕСТВОМ
Разработка и внедрение системы качества – одна из самых важных сфер деятельности предприятий. Сегодня качество становится политической, экономической и нравственной категорией. Качество – это здоровье, деньги, уровень душевного комфорта и достоинство нации и государства. Качество – это будущее России.
Для достижения поставленной цели повышения конкурентоспособности изделий должны быть решены следующие пять блоков задач:
• разработать инструментальные средства информационной поддержки жизненного цикла товаров и услуг;
192
• создать нормативно-методическое обеспечение информационной поддержки
товаров и услуг;
• разработать методы и средства подтверждения соответствия требованиям
качества и безопасности товаров и услуг;
• разработать методы и средства информационной поддержки систем менеджмента качества;
• разработать методологию и принципы информационно-телекоммуникационной технологии управления научно-технической деятельностью в системе образования и обеспечить ее экспертное сопровождение.
Для решения поставленных задач необходимо осуществить научно-методические и опытно-конструкторские разработки, создающие базу в области менеджмента качества и информационной поддержки жизненного цикла продукции (товаров и услуг). Для этого необходимо иметь соответствующие инструментальные
средства, позволяющие автоматизировать процесс создания, производства и эксплуатации изделий и соответственно на каждом из этих этапов управлять качеством.
Для создания инструментальных средств необходимо разработать комплект
математических моделей, охватывающий фазы и функции жизненного цикла продукции, а также методы информационной интеграции и системной поддержки
жизненного цикла продукции, и предложить способы их внедрения на предприятиях. Для этого:
• необходимо проанализировать и дать оценку существующим проблемам,
связанным с созданием и внедрением ИПИ-технологий;
• предложить и описать подходы к формированию моделей интегрированного
управления производством; разработать модели производственных систем; сформировать модели технологических процессов; разработать экономические модели
для оценки эффективности;
• методы информационной интеграции и системной поддержки жизненного
цикла продукции должны быть основаны на применении PDM (Product Data Management)-технологии и PDM-системы;
• методы должны предполагать использование PDM-системы не только для
хранения данных о продукции, но и для управления информационными процессами жизненного цикла (ЖЦ) продукции (управление потоками работ);
• способ внедрения должен предоставлять заказчику систему «под ключ»,
т. е. включать задачи обследования предприятия, реинжиниринг бизнес-процессов,
разработки проекта системы, настройки и адаптации PDM-системы, разработки
рабочих инструкций для пользователей, обучения пользователей, проведения
опытной эксплуатации системы, разработки стандартов предприятия и передачи
системы в промышленную эксплуатацию.
5.4. РЕАЛИЗАЦИЯ ИНФОРМАЦИОННОЙ ПОДДЕРЖКИ
СИСТЕМ МЕНЕДЖМЕНТА КАЧЕСТВА
Для реализации информационной поддержки систем менеджмента качества
необходимо разработать методы, которые должны:
193
• основываться на требованиях стандартов ГОСТ Р ИСО 9000:2001;
• информационная поддержка систем управления качеством должна основываться на применении автоматизированной системы управления данными о продукции;
• охватывать все процессы систем менеджмента качества в соответствии
с управленческим циклом PDCA и включать использование функции управления
потоками работ PDM-системы для планирования, выполнения и контроля процессов системы менеджмента качества.
Для повышения эффективности управления стоимостью жизненного цикла
продукции необходимо разработать методы реализации информационного обеспечения на основе требований отечественных нормативных документов и рекомендаций спецификации DEF 00-60.
Методы и средства необходимо разрабатывать с учетом защиты данных
от несанкционированного доступа, которые являются важным компонентом корпоративных информационных систем. Разрабатываемые методы и средства должны позволять использование электронной подписи и электронных документов
в системах управления данными об изделиях (PDM-системах).
Результаты работы должны представлять систему документации, необходимой для создания и эффективного использования систем менеджмента качества.
Для успешной деятельности предприятий на международных рынках предприятия
должны уже на этапе подготовки производства применять ИПИ-технологии на базе современного программного обеспечения. Использование ИПИ-технологий позволит не только хранить данные о продукции, но и управлять информационными
процессами жизненного цикла продукции.
Особое внимание необходимо уделить разработке системы управления качеством для комплекса измерительного, контрольного и испытательного оборудования.
При создании системы качества в числе первоочередных задач должна стоять
задача создания безопасных технологий, продукции и услуг. Для этого необходимо
разработать нормируемые показатели качества, безопасности и конкурентоспособности технологий, продукции и услуг на основе обязательных требований, правил,
документов ВТО и других международных организаций и форумов.
Методология проектирования и инструментальные средства систем менеджмента качества должны отвечать требованиям стандартов ИСО серии 90001:2000
(ИСО 9001, ИСО 9004, ИСО 19011) и стандартов ГОСТ Р ИСО 9000-2001 и основываться на применении систем автоматизированного документооборота.
Принимая во внимание ограниченные возможности предприятий в создании
КМК-технологий, целесообразно оказать государственную поддержку решению
задачи разработки и апробации типовых программно-технических средств обеспечения качества продукции, соответствующих требованиям международных стандартов ИСО 9000:2000. В случае решения указанной задачи на предприятиях могут
быть созданы эффективно действующие СМК на основе адаптации указанных программно-технических средств к продукции, технологиям и структуре производства
конкретного предприятия. Это даст возможность предприятиям многократно сократить стоимость разработки.
194
В настоящее время опыт практического применения показал, что в качестве
средства кардинального решения проблемы повышения качества и конкурентоспособности производимой продукции служат ИПИ-технологии. В настоящее время
ИПИ-технологии применяются на ряде ведущих предприятий-экспортеров
для электронного описания изделий и электронного представления технической
эксплуатационной документации.
В целом, в оборонной промышленности только начаты работы по созданию
нормативной, научно-методической и программно-технической базы, необходимой для внедрения всех составляющих ИПИ-технологий для решения задач электронного сопровождения экспортных контрактов.
Для решения проблем координации комплекса НИОКР в области разработки
и внедрения отечественных ИПИ-технологий в различных отраслях промышленности целесообразно апробировать результаты выполняемых исследований применительно к различным видам техники. В этой связи Минпромнауки России совместно с российскими агентствами оборонных отраслей промышленности выполняют пилотные проекты по внедрению ИПИ-технологий применительно к новейшим
видам техники. Выполнение указанных пилотных проектов позволит создать нормативно-правовую, научно-методическую и программно-техническую базу для внедрения ИПИ-технологий на предприятиях различных отраслей промышленности.
Вместе с тем в ближайшие годы потребность в ИПИ-технологиях может значительно превысить реальные возможности предприятий по кадровому, программно-техническому и финансовому обеспечению внедрения различных составляющих ИПИ-технологий, необходимых для решения задач электронного сопровождения конкретных экспортных контрактов. В этой ситуации необходимо
создание межведомственного центра промышленной информатики, отвечающего
за разработку и внедрение на предприятиях компьютерных технологий менеджмента качества (КМК-технологий) и технологий электронного сопровождения
наукоемкой продукции на всех этапах жизненного цикла (ИПИ-технологий).
5.5. ИЛП КАК МЕТОД ОПТИМИЗАЦИИ СТОИМОСТИ ЖЦ ИЗДЕЛИЯ
Важной задачей CALS-технологий является поддержка ЕИП жизненного цикла не только в процессе разработки, но и при продаже, внедрении, эксплуатации
и утилизации продукции. Для правильной организации эксплуатации изделий или
потребления услуг используются методы науки, именуемой логистикой. Принято
говорить о «логистической» или материально-технической поддержке послепродажного периода жизненного цикла продукции.
Логистику можно рассматривать в качестве способа оптимизации движения
материальных и информационных ресурсов в пространстве и во времени. В зависимости от стоящих задач ее применяют как внутри одной компании, так и между
различными компаниями, а также для работы с потребителем. Упрощенная формула логистики: нужный товар в необходимом количестве необходимого качества в нужное время в нужное место с минимальными затратами.
195
Современная логистика как наука зародилась в 80-х гг. ХХ в. в США и Японии. Ее сущность – в системном подходе к управлению производством (предприятием, отраслью, регионом, экономикой страны). Постепенно произошел переход
от частных концепций – производственной, транспортной логистики и т. д. –
к «интегрированной логистике».
На уровне предприятия она предполагает объединение усилий в сквозном
управлении материальными, информационными и прочими потоками всех участников полной логистической цепи предприятия: закупки–производство–
распределение–продажи–сервис. Предусматриваются три уровня ее внедрения:
1. Низший уровень – отдельные операции понимаются как логистические,
и ими управляют с точки зрения оптимизации по какому-либо критерию. Чаще
всего в качестве такого критерия выступает минимизация производственных издержек.
2. Средний уровень – наилучшее управление отдельными функциями или какими-то видами деятельности предприятия с точки зрения конечных целей. Создание локальных логистических систем в подразделениях или группах подразделений предприятия.
3. Высший уровень – образование интегрированной логистической системы
предприятия в целом.
На уровне кооперации предприятий или отрасли промышленности интегрированная логистика предусматривает функциональную интеграцию логистических
систем-участников логистической цепи в форме создания интегрированной логистической системы (ИЛС) с общим управлением. Появление концепции интегрированной логистической поддержки (ИЛП) изделий и интегрированных
логистических систем обусловлено стремлением максимально повысить эффективность эксплуатации сложной техники.
Главное преимущество ИЛС заключается в предотвращении неоправданных
потерь времени и ресурсов в процессе организации взаимодействия участников
при единой системе управления. Однако, будучи единой, эта система управления
может тем не менее быть и децентрализованной, т. е. иметь несколько управляющих узлов. В ИЛС возможности для маневра ресурсами существенно выше, чем на
отдельном предприятии с его сложившейся структурой и производственными
мощностями. В частности, ключевые управляющие моменты могут определять
конфигурацию всей системы.
В рамках ИЛС осуществляется управление следующими аспектами поддержки эксплуатации изделия:
• планирование обслуживания изделия (Maintenance planning);
• поддержка снабжения ресурсами (Supply support);
• оборудование для поддержки эксплуатации и тестирования изделия (Support
and Test equipment);
• обеспечение надежности и ремонтопригодности (Reliability and Maintainability;
• вспомогательное оборудование (Facilities);
• выработка требований к обслуживающему персоналу (Manpower and Human
factors);
196
• обучение персонала и учебное оборудование (Training and Training
equipment);
• техническая документация (Technical documentation);
• упаковка, хранение, транспортировка и т. д. (Packaging, Handling, Storage
and Transportation);
• утилизация изделия (Disposal).
Эффективность интегрированной логистики наиболее четко проявляется
в производстве и эксплуатации сложных и сверхсложных технических комплексов
различного назначения. Так, например, сложную логистическую проблему представляет собой постройка современного самолета или космического корабля. Так,
в создании американского истребителя F-22 участвуют около 4,5 тыс. поставщиков, производственную кооперацию которых необходимо координировать.
Системный подход к проектированию ЖЦ изделия и вытекающий из него
комплекс управленческих мероприятий, направленных на сокращение этих затрат,
объединяются понятием интегрированной логистической поддержки (ИЛП –
Integrated Logistic Support). Концепция ИЛП возникла почти одновременно с самой интегрированной логистикой как результат осмысливания многолетнего опыта эксплуатации военной техники в армиях США и Великобритании.
Интегрированная логистическая поддержка – методология оптимизации
стоимости ЖЦ изделия с учетом критериев его наилучшей пригодности к поддержке эксплуатации, надежности и ремонтопригодности, основанная на построении интегрированной логистической системы.
В понятие ИЛП входят:
• исследование состояния рынка и прогнозирование перспектив сбыта изделий, планируемых к производству;
• определение инфраструктуры системы обслуживания изделий в период эксплуатации, в том числе планирование процедур материально-технического обеспечения, диагностики состояния изделий, ремонта и т. п.;
• учет требований ремонтопригодности при проектировании изделий, разработка средств обслуживания сложной техники параллельно с разработкой самого
изделия;
• расчет надежности и длительности безотказной работы изделий;
• расчет затрат на производство и эксплуатацию изделий;
• определение состава и необходимого объема запасных частей;
• обучение обслуживающего персонала;
• поддержка связей между производителем и потребителем путем доступа потребителя к интегрированной базе данных изделия с целью упрощения диагностики состояния и ремонта изделий, а также получения изготовителем данных о неисправностях и отказах для принятия мер по повышению надежности изделий;
• классификация и кодификация изделий и материалов, необходимые для упрощения поиска нужных данных в справочниках и БД, исключения дублирования
проектов, ускорения составления заявок на поставки комплектующих и т. п.;
• разработка и сопровождение электронной эксплуатационной и ремонтной
документации;
197
• традиционные логистические процедуры, такие как упаковка, складирование, транспортировка изделий.
Пригодность к осуществлению поддержки эксплуатации (supportability) –
степень соответствия конструктивных характеристик изделия и интегрированной
логистической системы поддержки его эксплуатации требованию постоянной готовности изделия к работе или приведения его в готовность за приемлемое время.
Система интегрированной логистической поддержки (ИЛП-система) изделия – интегрированная логистическая система, обеспечивающая поддержку эксплуатации данного изделия в течение всего его ЖЦ в соответствии с требованиями
ИЛП.
ИЛП реализуется посредством применения специализированных информационных технологий (ИТ) и соответствующих программно-методических средств.
Базовым стандартом в области ИЛП, получившим в Европе de-facto статус
международного, является стандарт министерства обороны Великобритании DEF STAN 00-60: Интегрированная логистическая поддержка. Это новейший стандарт, в настоящее время состоит из двенадцати томов, охватывающих основные аспекты ИЛП.
Этот стандарт является «зонтичным» по отношению к различным аспектам
ИЛП. Регламентируя основные требования, он, в свою очередь, определяет возможности использования международных, национальных, военных стандартов
и спецификаций:
• MIL-HDBK-502 Acquisition Logistics – управление ресурсами в ходе жизненного цикла продукта. Под ресурсами понимаются все типы материальных
и информационных ресурсов, используемых на различных стадиях ЖЦ.
• MIL-PRF-49506 Logistics Management Information. Данная спецификация
описывает требования к форматам представления данных о продукте, необходимых для использования системами управления ресурсами.
• MIL-STD-974 Contractor Integrated Technical Information Service (CITIS) определяет требования к интегрированной системе информационно-технического
обслуживания исполнителей заказов (состав информации, права доступа), функциями которой являются совместное ведение контрактов и предоставление доступа
к информации о контрактах.
На нормы стандарта DEF STAN 00-60 иностранные заказчики ссылаются,
формулируя требования к системе ИЛП для отечественных изделий. Учитывая
«NATO CALS Handbook», стандарт США MIL-STD-1388, требования авиационной
спецификации AECMA 1000D, можно выявить основное содержание проблемы
ИЛП и сформулировать связанные с ней задачи.
Большинство сложных технических задач разрабатывается по специальному
заказу. Для таких изделий разработка ИЛП-системы начинается практически одновременно с разработкой самого изделия. В ходе разработки концепции изделия
вырабатываются также и общие принципы организации поддержки его эксплуатации. Зная концепцию, можно определить структуру и порядок функционирования
будущей ИЛП-системы изделия (рис. 5.1).
198
Этапу проектирования и производства изделия соответствует этап проектирования ИЛП-системы (на рис. 5.1 – проектирование стратегии поддержки эксплуатации). Здесь методом последовательного приближения определяется конструкция изделия, обеспечивающая наилучшую пригодность к поддержке эксплуатации. Каждый вариант конструкции имеет свои функциональные характеристики
и, соответственно, характеристики ИЛП. Поэтому возникает необходимость
в управлении конфигурацией изделия и его ИЛП-системы. Под управлением конфигурацией понимается соблюдение определенных правил и процедур изменения
конструкции и их документирования (спецификация министерства обороны США
MIL-STD.- 2549).
На этапе эксплуатации (на рис. 5.1 – поддержка эксплуатации изделия) постоянно осуществляется мониторинг и анализ состояний изделия и его ИЛПсистемы с целью проверки соответствия фактических и расчетных значений их
характеристик. Выявленное таким путем несоответствие фактической и расчетной
степени пригодности изделия к поддержке эксплуатации может повлечь за собой
пересмотр ИЛП-системы, а в худшем случае – конструкции или даже концепции
изделия.
По завершении утилизации изделия подсчитывается окончательная стоимость ЖЦ изделия и оценивается общая эффективность организации ИЛП. Такая
оценка вместе с архивными данными о функционировании ИЛП-системы может
использоваться при организации ИЛП для изделий аналогичного типа или назначения. На рис. 5.1 это стадия завершения поддержки эксплуатации изделия.
199
Главное, на что следует обратить внимание, – постоянный контроль за текущей или реальной стоимостью ЖЦ изделия. Важность жесткого регулярного контроля обусловлена необходимостью доказать пользователю, что полученная в конечном итоге стоимость ЖЦ изделия оптимальна.
Интегрированная логистическая поддержка (ИЛП) включает в себя следующие процедуры:
• логистический анализ (Logistic Support Analysis) изделия, выполняемый с
целью обеспечения необходимого уровня надежности, ремонтопригодности и пригодности к поддержке, а также установления требований:
– к конструкции изделия, размещению его агрегатов и узлов, подлежащих регулярному обслуживанию, замене и ремонту;
– к вспомогательному и испытательному оборудованию;
– к численности и квалификации эксплуатационного и обслуживающего персонала;
– к системе и средствам обучения;
– к номенклатуре и количеству запасных частей, расходных материалов и т. д.;
– к организации хранения, транспортировки, упаковки и т. д.
• планирование технического обслуживания и ремонта (ТОиР) изделия (Maintenance and Repair Planning):
– разработка концепции ТОиР, требований к изделию в части его обслуживания и реализации плана ТОиР;
• интегрированные процедуры поддержки материально-технического обеспечения (МТО) процессов эксплуатации, обслуживания и ремонта изделия (Integrated Supply Support Procedures Planning), в том числе:
– определение параметров начального и текущего материально-технического
обеспечения;
– кодификация предметов поставки;
– планирование поставок изделий;
– управление заказами на поставку предметов снабжения;
– управление счетами на оплату заказанных предметов снабжения
• меры по обеспечению персонала электронной эксплуатационной документацией (ЭЭД) и электронной ремонтной документацией (ЭРД) на изделие (Electronic Maintenance Documentation, Electronic Repair Documentation), принимаемые
на стадии проектирования и в процессе производства конкретных экземпляров
(партий) изделия. Указанная документация используется при закупке, поставке,
вводе в действие, при эксплуатации, сервисном обслуживании и ремонте изделия.
В системах ИЛП контролируются процессы поставки изделий, формирования
и исполнения заявок. Следует отметить, что ИЛП тесно связана с обеспечением
управления качеством продукции в соответствии со стандартами серии ISO 9000.
200
5.6. ЛОГИСТИЧЕСКИЙ АНАЛИЗ
Логистический анализ – группа важных задач, с выполнения которых начинается ИЛП. Под логистическим анализом (ЛА) понимают формализованную технологию всестороннего исследования как самого изделия, так и вариантов системы
его эксплуатации и поддержки с целью сокращения затрат на постпроизводственных стадиях жизненного цикла при обеспечении требуемого уровня готовности
изделия.
На ранних стадиях разработки (техническое предложение, эскизный проект)
основное внимание должно быть сосредоточено на оценке конструкции разрабатываемого изделия с точки зрения поддерживаемости и формирования требований
к изделию и системе поддержки. Многолетняя практика проектирования сложных
технических систем показывает, что:
• до 70 % стоимости жизненного цикла изделия определяются на стадии разработки ТЗ, требующей для своей реализации всего около 10 % стоимости ЖЦ;
• в процессе разработки окончательного проекта изделия (30 % стоимости
ЖЦ) фактически известны до 90 % стоимости ЖЦ.
Это значит, что именно на ранних стадиях разработки изделия, когда уже известна большая часть стоимости его ЖЦ, заложен наибольший потенциал ее сокращения. Именно решение данной задачи является главной особенностью логистического анализа (ЛА) как элемента ИЛП, в отличие от традиционного ЛА,
имеющего целью лишь минимизацию затрат ресурсов в логистических системах.
Применительно к ИЛП логистический анализ заключается в использовании
ряда методов научного и инженерного анализа в процессе разработки изделия
и его ИЛП-системы, чтобы наилучшим образом обеспечить пригодность изделия
к осуществлению поддержки эксплуатации.
На рис. 5.2 представлен один из вариантов организации ЛА. Отсюда видно,
что существуют две фазы ЛА:
1. Стадия проектирования изделия. Вырабатываются решения, позволяющие
существенно снизить стоимость ЖЦ изделия.
2. Стадия проектирования ИЛП-системы изделия (для спроектированного изделия). Определяются меры и ресурсы, необходимые для поддержки эксплуатации
изделия.
ЛА начинается с момента получения технического задания на изделие и организацию его ИЛП, т. е. с постановки задачи. Основным результатом этой стадии
является выработка стратегии проведения ЛА, соответствующих методов и средств.
На стадии проектирования и производства изделия главная задача состоит
в том, чтобы конструктивно обеспечить наилучшую пригодность изделия к поддержке эксплуатации, т. к. здесь прогнозируются затраты и определяются ресурсы,
необходимые для поддержки изделия в нужном состоянии. Результаты ЛА отражаются в отчетной документации, представляемой заказчику, и частично в БД ЛА
(рис. 5.3), предназначенной для информационного обслуживания всех участников
жизненного цикла изделия и являющейся доступной обслуживающему персоналу.
201
Рис. 5.2. Пример организации логистического анализа
База данных логистического анализа (LSA Record) – часть документации
ЛА, содержащая данные, предназначенные для выявления потребностей в ресурсах
поддержки эксплуатации изделия, таких как:
• планируемые потребности в ресурсах;
• фактические потребности в ресурсах.
БД ЛА поддерживается в течение всего ЖЦ ИЛП-системы изделия, связана с
АСУ эксплуатации изделия и используется для следующих целей:
• проведения повторного ЛА при модернизации изделия или среды его эксплуатации;
• формирования комплексной системы материально-технического обеспечения (МТО) изделия;
202
• обмена опытом с другими проектами изделий;
• формирования стандартизованных отчетов ЛА.
Стандарт 00-60 рекомендует создавать базу данных ЛА в виде реляционной
базы данных (в общем виде она содержит более 100 таблиц и почти 600 элементов данных) или электронных таблиц. Однако она может быть реализована и в PDM-системе.
В состав БД ЛА (рис. 5.4) входит комплекс из 104 реляционных таблиц, содержащих следующие результаты ЛА:
Таблицы типа A: требования по эксплуатации и обслуживанию.
Таблицы типа B: показатели требуемого уровня обслуживания (RMA), данные причинно-следственного анализа возможных отказов (FMECA), результаты
анализа ремонтопригодности изделия и пригодности к поддержке.
Таблицы типа C: выполняемые задачи, анализ выполняемых задач, данные
по персоналу и поддержке эксплуатации.
Таблицы типа E: данные о вспомогательном и учебном оборудовании, учебных материалах.
Таблицы типа F: данные об инфраструктуре для поддержки эксплуатации.
Таблицы типа G: требования к квалификации персонала.
Таблицы типа U: тестируемые узлы и агрегаты, данные по тестированию.
Таблицы типа X: требования к организации перекрестных ссылок.
А
Требования п о эксплуатации
и обслуживанию
В
Уровни обслуживания,
анализ отказов, ремонтопригодность
Таблицы БД ЛА
С Задачи поддержки эксплуатаци и,
персонал
Е
Вспомогательное, учебное
оборудование, учебные материалы
F
Инфраструктура поддержки
эксплуат ации
G
Требования к квалификации
персонала
U
Тестируемые узлы и агрегаты,
данные те стирования
X
Организация перекрестных ссылок
Рис. 5.4. База данных логистического анализа
Как видно из рис. 5.3, кроме деления на группы ЛА, ТОиР, МТО, управления
заказами, разработки технической документации часть задач ИЛП может быть разделена
на группы проектирования средств обслуживания, разработки документации и обучения
персонала.
203
5.7. ГРУППЫ ЗАДАЧ ЛОГИСТИЧЕСКОГО АНАЛИЗА
На стадии подготовки контракта на разработку и поставку изделия поставщик
должен представить заказчику результаты ЛА. А именно:
1. Показать, как и какие информационные технологии (ИТ) использованы при
решении задач АЛП и как будет обеспечено совместное использование данных
АЛП для ИЛП и других задач.
2. Оценить характеристики «пригодности к поддержке», в том числе:
• показать, как и какие ИТ будут применены в качестве одного из факторов,
обеспечивающих заданный уровень «пригодности к поддержке»;
• оценить, как в проекте учтены ограничения на логистические ресурсы;
• описать опыт применения ИТ в разработке и эксплуатации существующего
изделия – прототипа;
• показать, как и какие ИТ будут использованы в процессе проектирования
для улучшения характеристик «обслуживаемости» изделия.
3. Представить результаты оптимизации системы логистической поддержки.
4. Оценить ресурсы, необходимые для логистической поддержки изделия.
На более поздних стадиях разработки (технический проект) и в процессе производства задача ЛА заключается в проектировании средств поддержки изделия,
разработке перечня задач по обслуживанию и ремонту изделия и оценке ресурсов,
необходимых для их выполнения. На этапе эксплуатации должен быть обеспечен
сбор статистического материала для оценки результатов ЛА и для анализа новых
проектов.
Вся информация, получаемая и используемая в процессе АЛП, должна храниться в специализированной БД ЛА. В ней фиксируется конкретная конфигурация изделия, требования и процедуры по обслуживанию. БД ЛА используется для
разработки других элементов ИЛП, таких как электронная эксплуатационная документация, учебные материалы и т. д. На стадии эксплуатации в БД АЛП поддерживаются данные о фактической конфигурации изделия с учетом возможных изменений.
Информация о ходе эксплуатации и фактических характеристиках «пригодности к поддержке» должна передаваться проектанту, обеспечивая обратную связь и
возможность дополнения и корректировки результатов первоначального анализа.
Поэтому БД АЛП физически должна состоять из двух частей:
1) непоставляемая часть, находящаяся в распоряжении подрядчика;
2) поставляемая часть, передаваемая заказчику.
Поставляемая часть должна обеспечить функции обслуживания изделия заказчиком, в то время как непоставляемая часть – функции логистической поддержки и сопровождения изделия подрядчиком. При поставке изделия подрядчик должен передать заказчику поставляемую часть БД ЛА, заполненную всей необходимой информацией о данном экземпляре изделия.
Стандарт 00-60 выделяет в логистическом анализе 15 стандартизованных задач, сгруппированных в 5 серий:
204
100 – Планирование и управление работами по ЛА.
200 – Служебное назначение изделия и система поддержки его эксплуатации.
300 – Подбор и оценка альтернатив.
400 – Разработка требований к ресурсам логистической поддержки.
500 – Оценка «пригодности к поддержке».
Данный перечень задач установлен для ИЛП-проектов Министерства обороны
Великобритании (табл. 5.1). Во всех остальных случаях он позиционируется как
образец, допускающий корректировку с учетом особенностей конкретного проекта.
Система задач и последовательность их выполнения построены так, чтобы
снизить вероятность неудачных проектных решений, влияющих на эффективность
эксплуатации изделия. Подразумевается, что одна из важнейших целей ЛА – доказать потребителю, что возможные меры по сокращению стоимости владения изделием приняты.
Выполнение ЛА носит итеративный характер. Задачей 501 (см. табл. 5.1) завершается каждая стадия ЛА. В зависимости от результата ее выполнения осуществляется переход к следующей стадии или возврат к одной из предыдущих.
Таблица 5.1
ЗАДАЧИ ЛОГИСТИЧЕСКОГО АНАЛИЗА
Группа задач
1
100. Планирование
и организация работ
Назначение
группы задач
2
Подготовка
набора
исходных
данных для
планирования
анализа
и проведения,
рецензирования
Задачи и подзадачи
3
101. Разработка предварительной программы работ
по выполнению ЛА
101.2.1. Постановка задачи обеспечения «пригодности
к поддержке», уточнение перечня решаемых задач ЛА.
101.2.2. Оценка затрат на выполнение ЛА 101.2.3.
Корректировка программы работ по ЛА.
102. Разработка плана ЛА
102.2.1. Разработка детального плана ЛА 102.2.2.
Корректировки плана.
102.2.3. Подготовка технических требований к контракту
на поставку (DID к CDRL).
103. Рецензирование программы ЛА и проекта изделия
103.2.1. Разработка процедур рецензирования.
103.2.2. Рецензирование проекта и требований к нему.
103.2.3. Рецензирование программы ЛА.
Контроль результатов ЛА.
103.2.4. Консультации с заказчиком по вопросам ЛА
205
Продолжение табл. 5.1
1
200.
Служебное
назначение
изделия
и система
поддержки
его эксплуатации
2
Формирование
требований
к системе
поддержки
и связанных
с ней требований к проекту
на основе
сравнения
с существующими аналогами
3
201. Анализ технической спецификации нового изделия
201.2.1. Анализ факторов «пригодности к поддержке».
201.2.2. Документирование количественных показателей
«пригодности к поддержке».
201.2.3. Консультации с эксплуатационными и техническими
службами.
201.2.4. Подготовка и корректировка отчета по проведенному
анализу технического описания.
202. Стандартизация элементов изделия и системы
поддержки эксплуатации
202.2.1. Установление ограничений.
202.2.2.Установление требуемых характеристик «пригодности
к поддержке».
202.2.3. Разработка рекомендаций по стандартизации.
202.2.4. Документирование возможных рисков.
203. Сравнительный анализ
203.2.1. Подбор изделий-аналогов.
203.2.2. Выбор базового аналога для сравнения.
203.2.3. Характеристики изделия-аналога.
203.2.4. Качественные проблемы «пригодности к поддержке»,
выявленные у изделия-аналога (которых надо избежать
у нового изделия).
203.2.5. Общие факторы «пригодности к поддержке»,
затрат и параметров готовности аналога.
203.2.6. Специфические факторы (факторы «пригодности
к поддержке», затрат и параметров готовности компонентов
нового изделия, для которых нет аналогов в базовом изделии).
203.2.7. Корректировка параметров выбранного базового изделияаналога.
203.2.8. Возможные риски и предположения, связанные
с выбором базового изделия-аналога.
204. Технологические решения
204.2.1. Разработка рекомендаций к проекту, направленных
на улучшение «пригодности к поддержке».
204.2.2. Корректировка технических требований к проекту.
204.2.3. Возможные риски при реализации предлагаемых
улучшений в проекте.
205. «Пригодность к поддержке» и связанные
с ней параметры проекта
205.2.1. Характеристики «пригодности к поддержке».
205.2.2. Требования к «пригодности к поддержке» на стадии ТЭО.
205.2.3. Требования к «пригодности к поддержке», включаемые
в контракт.
205.2.4. Задачи «пригодности к поддержке»» и связанные
с этим риски.
205.2.5. Минимально необходимые требования к «пригодности
к поддержке».
205.2.6. Ограничения НАТО.
205.2.7. Уточненные требования к «пригодности к поддержке»
206
Продолжение табл. 5.1
1
2
300. ПодРазработка
бор и оценка системы,
альтернатив обеспечивающей
наилучший
баланс затрат,
сроков, характеристик
и «пригодности к поддержке»
3
301. Функциональные требования
301.2.1. Разработка функциональных требований к изделию.
301.2.2. Разработка специальных функциональных требований
(специфичных для данного изделия) или влияющих
на показатели «пригодности к поддержке» изделия.
301.2.3. Возможные риски, связанные с реализацией
функциональных требований.
301.2.4. Задачи эксплуатации и обслуживания.
301.2.5. Выявление недостатков проекта, требующих его
корректировки, связанных с уточненными функциональными
требованиями.
301.2.6. Корректировка функциональных требований.
302. Варианты системы поддержки
302.2.1. Альтернативные варианты концепции системы
поддержки.
302.2.2. Корректировки концепции поддержки.
302.2.3. Альтернативные планы поддержки.
302.2.4. Корректировки плана поддержки.
302.2.5. Возможные риски.
303. Оценка альтернатив и выбор решения
303.2.1. Критерии выбора.
303.2.2. Разработка рекомендаций по системе поддержки
для каждого варианта проекта изделия.
303.2.3. Разработка рекомендаций к выбору проектных решений.
303.2.4. Анализ характеристик готовности.
303.2.5.Анализ вопросов персонала и человеческого фактора.
303.2.6. Анализ вопросов обучения.
303.2.7. Анализ ремонтопригодности.
303.2.8. Анализ вопросов диагностики.
303.2.9. Сравнительные оценки между новым и существующими
изделиями.
303.2.10. Принятые решения по вопросам энергообеспечения.
303.2.11. Принятые решения по вопросам живучести.
303.2.12. Принятые решения по вопросам транспортабельности.
303.2.13. Принятые решения по вопросам инфраструктуры
207
Окончание табл. 5.1
1
400.
Разработка
требований
к ресурсам
логистической поддержки
2
Определение
требований
к ресурсам
логистической
поддержки,
разработка
планов постпроизводственной поддержки
500. Оценка поддерживаемости
Проверка
выполнения
заданных
требований
и устранение
недостатков
3
401. Оценка обеспеченности ресурсами
401.2.1. Анализ задачи.
401.2.2. Документирование результатов анализа.
401.2.3. Выявление критических ресурсов, необходимых для
эксплуатации и поддержки изделия.
401.2.4. Требования и рекомендации по обучению.
401.2.5. Доработка проекта изделия.
401.2.6. Разработка плана организационных мероприятий,
направленных на минимизацию рисков, связанных с критическими ресурсами.
401.2.7. Требования к транспортировке.
401.2.8. Требования к системе снабжения (в том числе форматы документов, требования к системе начального обеспечения).
401.2.9. Утверждение ключевых данных, документированных
в БД ЛА (LSAR).
401.2.10.Подготовка отчетов на основе БД ЛА (LSAR).
401.2.11. Корректировка результатов ЛА (БД ЛА).
401.2.12. Присвоение кодов (кодификация) и регистрация предметов снабжения.
402. Предварительная оценка результатов внедрения (боевого применения)
402.2.1. Оценка результатов внедрения нового изделия в существующую систему поддержки.
402.2.2. Источники кадрового обеспечения повышения квалификации, необходимые для освоения нового изделия.
402.2.3. Снижение готовности изделия вследствие невозможности
получения требуемых логистистических ресурсов.
402.2.4. Требования к ресурсам боевого обеспечения и источники их получения.
402.2.5. Планы решения выявленных проблем.
403. Анализ постпроизводственной поддержки
403.1. План постпроизводственной поддержки (в том числе при
прекращении производства)
501. Испытания, оценка и проверка «пригодности
к поддержке»
501.2.1. Методика испытаний и оценки.
501.2.2. Разработка перечня компонентов системы поддержки,
подлежащих оценке.
501.2.3. Задачи и критерии оценки.
501.2.4. Корректировки и корректирующие действия по
вопросам, не затронутым испытаниями. Корректировка
документации и базы данных ЛА.
501.2.5. План оценки «пригодности к поддержке».
501.2.6. Оценка «пригодности к поддержке»
Заказчик участвует в процессе логистического анализа и может контролировать его ход. По завершении очередной задачи ЛА заказчику предоставляется отчет. Стандарт 00-60 особо выделяет отчеты базы данных, определяя их форму
и содержание.
208
5.8. ПРИГОДНОСТЬ К ПОДДЕРЖКЕ
Однако ИЛП рассматривает не только готовность изделия к осуществлению
поддержки эксплуатации. Надежность и ремонтопригодность по прежнему остаются важными критериями оптимизации стоимости ЖЦ, а потому ЛА имеет ряд
соответствующих методик:
• анализ последствий возможных неисправностей и путей их предотвращения
(Failure modes Effects and Criticality Analysis – FMECA);
сравнительный анализ эффективности методов организации обслуживания
изделия, позволяющих предотвратить возникновение неисправностей (Reliability
Centered Maintenance Analysis RCMA);
• анализ качества обслуживания изделия (Level of Repair Analysis- LORA).
В ходе ЛА определяется концепция технического обслуживания и ремонта,
а также требования к конструкции изделия, в частности вырабатывается соответствующий регламент, обосновываются требования к вспомогательному оборудованию и подготовке персонала. Одним из результатов выполнения ЛА может являться, например, формирование некоторого интегрального показателя (функционала), характеризующего эффективность ИЛП-системы (рис. 5.5):
S = (MTBF,MTTR,RST,MTBA,MTBR,ROA,RML),
Рис. 5.5. Пригодность к поддержке
209
где MTBF (Mean Time between Failures) – среднее время между отказами оборудования; MTTR (Mean Time to Repair) – среднее время ремонта; RST (Required
Standby Time) – среднее время восстановления (приведения в рабочее состояние)
после отказа; MTBMA (Mean Time between Maintenance Actions) – среднее время
между обслуживанием; MTBR (Mean Time between Removals) – среднее время между заменами узлов или деталей; ROA (Required Operational Availability) – требуемый уровень готовности; RML (Required Maintenance Level) – требуемый уровень
обслуживания.
Конкретный вид этого функционала и методика оценки пригодности к поддержке эксплуатации по его количественному значению будут определяться организацией, осуществляющей ЛА.
Помимо данных, прямо связанных с изделием, и характеристик «пригодности
к поддержке» результатом ЛА являются:
• требования к вспомогательному оборудованию, к которому относится стационарное и мобильное оборудование, необходимое для эксплуатации и технического обслуживания изделия, в том числе универсальное оборудование, транспортное оборудование, инструмент, метрологическое и контрольно-измерительное
оборудование, диагностическое оборудование и программное обеспечение;
• требования к инфраструктуре системы эксплуатации и ремонта, включающей здания, сооружения, системы энергоснабжения и т. д.;
• требования к количественному и качественному составу персонала и уровню его квалификации;
• требования к подготовке персонала и средствам обучения;
• требования, ресурсы и процедуры, связанные с упаковкой, хранением
и транспортированием изделия и вспомогательного оборудования, в том числе
требования к условиям внешней среды (температура, влажность, атмосферное давление, удары и вибрации и т. д.);
• особенности работы с опасными материалами, условия их краткосрочного
долгосрочного хранения.
Результаты ЛА представляются в форме реляционной базы данных (см. рис. 5.4).
5.9. ВЫБОР ЗАДАЧ ЛОГИСТИЧЕСКОГО АНАЛИЗА ДЛЯ КОНКРЕТНОГО ПРОЕКТА
Итак, выбор задач ЛА для конкретного проекта определяется следующими
элементами:
• Договоренность между поставщиком и заказчиком.
• Вид поставляемой продукции.
• Наличие статистической информации по данному или аналогичному типу
продукции.
• Стадия проекта.
• Свобода проектирования.
• Ограничения по времени и финансированию
В процессе решения задач ЛА определяется структура изделия и назначаются
коды (рис. 5.6.).
210
Код (акроним) конечного изделия (End Item Acronym Code – ELAC,
DED 096) – уникально идентифицирует конечное изделие.
Логистический контрольный номер – ЛКН (Logistic Control Number –
LCN, DED 199) – уникально идентифицирует компонент или функцию конечного изделия (совместно с двум\ следующими кодами).
Тип ЛКН (LCN Type, DED 203). Указывает тип разбиения (функциональное или физическое).
Альтернативный логистический номер – АЛН (Alternative LCN – ALC,
DED 019). Код, присваиваемый различным исполнениям одного компонента.
Рис. 5.6. Структура изделия и коды
В заключительной стадии решаются следующие задачи (рис. 5.7).
Рис. 5.7. Задачи, решаемые на заключительной стадии ЛА
Результаты ЛА отражаются в отчетной документации, представляемой заказчику, и частично в базе данных ЛА (см. рис. 5.4).
Заказчик участвует в процессе логистического анализа и может контролировать его ход.
По завершении очередной задачи ЛА заказчику предоставляется отчет
(рис. 5.8). Стандарт 00-60 особо выделяет отчеты базы данных, определяя их форму и содержание. Возможность подрядчика организовать ИЛП в значительной мере выражена его способностью предоставить заказчику отчеты ЛА в срок
и в соответствующей форме.
Номер отчета
LSA-001
Английское название отчета
Man-Hours by Skill Speciality
Code and Level of Maintenance
LSA-003
LSA-004
Maintenance Symmaru
Maintenance Allocation
LSA-007
Sypport Equipment Requirements
Русское название отчета
Распределение количества человеко-часов по квалификационным требованиям
и уровням обслуживания
Сводные данные по обслуживанию
Карта распределения работ по техническому обслуживанию
Рис. 5.8. Фрагменты таблицы отчетов
211
Использование результатов ЛА на стадиях ЖЦ показано на рис. 5.9.
В целом система задач ЛА и последовательность их выполнения построены
так, чтобы снизить вероятность неудачных проектных решений, влияющих на эффективность эксплуатации изделия. По аналогии со стандартами серии ISO9000,
направленными на построение системы, обеспечивающей заданный уровень качества и возможность адекватно демонстрировать потребителю способность управлять качеством, технологии и стандарты ЛА направлены на то, чтобы адекватно
доказать потребителю, что все меры, обеспечивающие сокращение стоимости владения изделием, приняты.
Рис. 5.9. Использование результатов ЛА на стадиях ЖЦИ
До недавнего времени процесс ЛА регламентировался стандартом Министерства обороны США MIL-STD-1388. Более современным и универсальным является, как указано выше, стандарт Министерства обороны Великобритании DEF
STAN 00-60, de-facto признанный в Европе в качестве международного.
Стандарт 00-60 рекомендует по возможности использовать электронную документацию на изделие для информационного обмена между поставщиком и заказчиком. Только если это невозможно, допускается применение традиционной
бумажной документации.
В состав электронной документации включаются следующие данные:
• технические данные об обслуживании изделия;
• срочная и временная информация об изделии и поставках;
• документация на программное обеспечение;
• документация, связанная с организацией закупок предметов МТО, включая
иллюстрированные каталоги деталей;
• идентификационная информация о предметах МТО;
• комплект технической документации на изделие, включая чертежи; отчеты ЛА.
212
5.10. ИНТЕГРИРОВАННЫЕ ПРОЦЕДУРЫ ПОДДЕРЖКИ
МАТЕРИАЛЬНО-ТЕХНИЧЕСКОГО ОБЕСПЕЧЕНИЯ
Стандарт AECMA S2000M посвящен вопросам материально-технического
обеспечения, технического обслуживания и ремонта в авиационной промышленности. По своему назначению близок к стандарту DEF STAN 00-60. Включает
разделы, описывающие планирование МТО, кодификацию, управление заказами,
счетами, ремонтом.
В стандарте описаны информационные модели МТО. Для примера часть информационной модели на языке Express-G приведена на рис. 5.10 (указана лишь
часть сущностей и атрибутов).
Рис. 5.10. Фрагмент модели связи структуры изделия и его МТО
Физической реализацией ИЛП-системы, связанной с производством и функционированием изделия, является комплексная система (КС) материальнотехнического обеспечения (МТО). КС МТО формируется как часть ИЛП-системы
изделия и распространяется не только на само изделие, но и на все вспомогательное оборудование.
КС МТО – это комплекс стандартизованных процедур, охватывающий такие
процедуры, как:
• кодификация предметов материально-технического обеспечения (Codification);
• определение параметров начального МТО (Initial Provisioning);
• определение параметров текущего (регулярного) МТО (Provisioning);
• планирование закупок предметов (Procurement Planning);
• управление поставками (Supply Management);
• управление заказами (Order Administration);
213
• управление счетами (Invoicing).
• организация текущих ремонтов.
В рамках одного предприятия могут существовать несколько относительно
независимых систем МТО для каждого вида используемой техники. Управление
и координация МТО на предприятии возложены на АСУ предприятия.
При создании комплексной системы МТО используется информация, поступающая из следующих источников:
• результаты ЛА в части требований к ресурсам, необходимым для осуществления поддержки эксплуатации;
• предыдущие проекты (готовой системы поставок или ее частей);
• каталоги запасных частей, в том числе – иллюстрированные (данные об альтернативных вариантах запчастей и материалов).
Кодификация предметов МТО представляет собой четко регламентированную
стандартами процедуру присвоения этим предметам кодовых обозначений, однозначно понимаемых всеми службами поставщиков и потребителей, причастными
к соответствующим процессам. Характерной особенностью этих обозначений является их ориентированность на компьютерную обработку. Цель кодификации состоит в сокращении номенклатуры закупаемых изделий и комплектующих, исключении неоправданного дублирования и предоставлении необходимой информации
потребителям и поставщикам.
Определение параметров начального МТО состоит в формировании перечня
необходимого набора запасных частей и расходных материалов, необходимых для
поддержки функционирования изделия в начальный период его эксплуатации, когда текущее МТО может по тем или иным причинам оказаться еще не налаженным. Состав этого набора, как в отношении номенклатуры необходимых предметов, так и в отношении их количества, определяется расчетами, выполняемыми
в процессе ЛА. В состав средств и предметов начального МТО, как правило, включают запасные части и материалы, необходимые для эксплуатации не только самого изделия, но и вспомогательного оборудования. В процессе организации начального МТО могут быть подготовлены контракты с фирмами – поставщиками
соответствующей продукции. Обычно период действия начального МТО ограничивается сроком до двух лет.
Номенклатура и объемы поставок, т. е. параметры текущего МТО, также определяются расчетами, выполняемыми в процессе ЛА, и затем корректируются
в зависимости от фактических условий эксплуатации изделия. При этом широко
используются иллюстрированные каталоги деталей и элементов изделия, подготовка которых также происходит в процессе ЛА.
Планирование закупок (ПЗ) представляет собой метод запроса и получения
от промышленных предприятий сведений о ценах на предметы МТО, включая
прайс-листы поставщиков. В соответствии со стандартами процедуры ПЗ охватывают два вида деловой практики:
Процедуры направления запроса о ценах на конкретные предметы МТО
от покупателя потенциальному поставщику и последующего ответа поставщика.
Процедуры запроса покупателем актуального прайс-листа на некоторую номенклатуру предметов МТО и предоставления такого прайс-листа поставщиком
214
в ответ на запрос покупателя. Возможна также процедура предоставления этих
данных покупателю по собственной инициативе поставщика.
Стандарты жестко регламентируют форму и содержание запросов и ответов
(сообщений) для обоих случаев, предусматривают формы и процедуры согласования цен и способы кодирования соответствующих разным ситуациям документов.
На основании результатов ПЗ определяется, у каких поставщиков будут приобретаться те или иные предметы МТО. Именно эти сведения и составляют содержание
плана закупок. Эти данные используются на последующих стадиях ИЛП,
т. е. при управлении заказами (заявками) и ведении счетов.
На основании результатов ПЗ определяется, у каких поставщиков будут приобретаться те или иные предметы МТО, что используется в дальнейшем
при управлении заказами и ведении счетов.
Управление поставками предусматривает выполнение таких процедур, как
оценка уровня текущих запасов по всем предметам МТО, принятие своевременных
решений о необходимости пополнения этих запасов, подготовка соответствующих
заявок, контроль качества поступающих предметов МТО, организация их хранения
и выдачи. На выполнение всех этих процедур существуют предусмотренные стандартами правила и инструкции, определяющие состав и последовательность необходимых действий, а также форму и содержание сопроводительных документов.
Управление заказами объединяет все виды действий, осуществляемых с заказом (заявкой) от момента его выдачи заказчиком поставщику и до подтверждения
доставки. Это означает, что управление заказами предполагает также и управление
поставками.
В данном случае между заказчиком и поставщиком происходит информационный обмен, в ходе которого используются следующие транзакции:
• размещение заказа (заказчик → поставщик);
• получение справок о размещенном заказе (заказчик → поставщик → заказчик);
• подтверждение приема заказа (поставщик → заказчик);
• отказ в приеме заказа (поставщик → заказчик);
• извещение об изменении несущественных параметров заказа (поставщик →
заказчик);
• извещение о выполнении заказа (поставщик → заказчик).
Управление поставками предусматривает выполнение таких процедур, как:
• оценка уровня текущих запасов по всем предметам МТО;
• принятие своевременных решений о пополнении этих запасов;
• подготовка соответствующих заявок;
• контроль качества поступающих предметов МТО;
• организация их хранения и выдачи.
Формат и содержание транзакций регламентированы стандартами.
Управление счетами на оплату заказанных предметов снабжения – информационный обмен между поставщиком и заказчиком при передаче счетов и данных о счетах на оплату в электронном виде. При этом используются следующие
транзакции:
1. Отправка счета (Поставщик – Заказчик).
2. Подтверждение приема счета к оплате (Заказчик – Поставщик).
215
216
3. Отказ от оплаты счета (Заказчик – Поставщик).
4. Отправка платежного требования (Поставщик – Заказчик).
5. Прием платежного требования (Заказчик – Поставщик).
6. Отказ от платежного требования (Заказчик – Поставщик).
7. Запрос данных о состоянии платежа (Поставщик – Заказчик).
8. Ответ на запрос о состоянии платежа (Заказчик – Поставщик).
9. Извещение о состоянии платежа (Заказчик – Поставщик).
Формат и содержание транзакций регламентированы стандартами.
Организация текущих ремонтов на данный момент не регламентируется
стандартами на ИЛП, а потому при их проведении следует руководствоваться существующими специализированными стандартами.
Таким образом, состав ИЛП можно представить в следующем виде (рис. 5. 11).
5.11. РЕГЛАМЕНТ ТЕХНИЧЕСКОГО ОБСЛУЖИВАНИЯ И РЕМОНТА ИЗДЕЛИЯ
Планирование процессов технического обслуживания и ремонта (ТОиР) в системах ИЛП предполагает:
• разработку концепции ТОиР;
• анализ и конкретизацию требований к изделию в части его обслуживания
и ремонта;
• разработку и оперативную корректировку плана ТОиР.
Концепция ТОиР предопределяет стратегию этих работ и их системную организацию.
Система ТОиР – совокупность взаимосвязанных технических средств, специальной технической документации и исполнителей, необходимых для поддержания
и восстановления качества изделий, относящихся к компетенции этой системы.
Принято различать следующие виды ТО изделий:
• ТО при использовании;
• ТО при хранении;
• ТО при перемещении;
• ТО при ожидании использования по назначению.
Помимо перечисленных выше понятий в стандарте DEF STAN 00-60 введено
понятие уровня ТОиР, которое применительно к отечественным оборонным условиям может быть интерпретировано следующим образом:
• нулевой уровень: ТОиР, выполняемые силами персонала, непосредственно
эксплуатирующего изделие (экипажа);
• первый уровень: ТОиР, выполняемые силами персонала подразделения (части), в составе которого эксплуатируется изделие (в армейских условиях – батальонные, полковые ремонтные службы);
• второй уровень: ТОиР, выполняемые силами персонала соединения, в составе
которого эксплуатируется изделие (корпусные, дивизионные, армейские ремонтные
службы);
• третий уровень: ТОиР, выполняемые силами персонала специализированных предприятий фронтового (окружного) подчинения;
• четвертый уровень: ТОиР, выполняемые силами персонала предприятияизготовителя.
217
Каждому уровню соответствует свой набор задач, требования к численности
и квалификации обслуживающего и ремонтного персонала, к количеству и номенклатуре запасных частей и заменяемых агрегатов, к составу специального оборудования и т. д.
Конкретизация изложенных выше положений и представлений служит основой содержания концепции ТОиР, разрабатываемой, как правило, поставщиком
изделия и согласуемой с его заказчиком.
Требования к изделию в отношении ТОиР определяются на основе данных
ЛА, содержащихся в БД ЛА, и уточняются по результатам реальной эксплуатации
в различных условиях.
На основе концепции и результатов анализа требований разрабатывают и реализуют следующие мероприятия:
• создание единой системы управления ТОиР, предусматривающей методы
и «механизмы» улучшения показателей надежности, безотказности, долговечности, ремонтопригодности, сохраняемости, что в итоге должно минимизировать
эксплуатационные затраты;
• организация распределенной системы сбора и обработки службами заказчиков (эксплуатантов) статистической информации о значениях вышеуказанных показателей, а также данных о номенклатуре и количестве используемых запасных
частей для изделия и его компонентов; эти данные извлекаются из специальных
документов – формуляров изделия, его агрегатов и систем, в которых фиксируются
результаты проведения операций ТОиР, факты замены компонентов, календарные
сроки выполнения операций (начало, конец), сведения о работниках, выполнявших
операцию и т. д.;
• выполнение службами заказчиков и поставщика централизованного анализа
накопленных эксплуатационных и логистических данных;
• проведение согласованной динамической корректировки планов ТОиР;
• подготовка и переподготовка персонала по обеспечению перечисленных
выше мероприятий.
План ТОиР разрабатывается в нескольких альтернативных вариантах с учетом
распределения работ по упомянутым выше уровням, назначения обслуживающего
и ремонтного персонала, обладающего необходимой квалификацией, наличия необходимых запчастей и расходных материалов и т. д. Планируются календарные
даты, трудоемкость работ и их стоимость. Заказчик выбирает наиболее подходящий ему вариант. При расчетах, связанных с планированием ТОиР, используются
следующие основные показатели:
• средняя продолжительность технического обслуживания (ремонта);
• средняя трудоемкость технического обслуживания (ремонта);
• средняя стоимость технического обслуживания (ремонта);
• средняя суммарная продолжительность технических обслуживаний (ремонтов);
• средняя суммарная трудоемкость технических обслуживаний (ремонтов);
• средняя суммарная стоимость технических обслуживаний (ремонтов);
• коэффициент готовности;
• коэффициент технического использования.
Регламент технического обслуживания (ТО) изделия, его систем и узлов содержит, как правило, перечень работ с указанием периодичности и/или условий их вы218
полнения. Регламент ТО не содержит полного описания выполняемых работ,
а включает только их краткое описание и ссылки на соответствующие технологические карты.
Принято рассматривать следующие виды регламентов ТО:
• линейный регламент – перечень работ, выполняемых при некотором событии,
произошедшем с изделием. К таким событиям, например, относятся взлет/посадка
самолета, подготовка к повторному полету и т. п.;
• плановый регламент – перечень работ, выполняемых с определенной периодичностью либо при определенной наработке изделия или его составных частей;
• обслуживание при хранении – перечень работ, выполняемых при хранении
изделия;
• сезонное обслуживание – перечень работ, выполняемых в указанное время года при подготовке к новому сезону.
Для описания перечисленных видов регламента используются соответствующие
подтипы МД «Регламент технического обслуживания».
Линейный регламент (объект DEFINSPEC) содержит перечень работ со ссылками
на соответствующие процедурно-технологические МД. Весь перечень работ должен
выполняться при определенном условии/событии, таком как, например, подготовка
к полету. Структура МД для описания линейного регламента представлена на рис.
5.12.
Объект INSPECTION содержит описание условия/события, при наступлении
которого должен быть выполнен весь перечень работ, заданных объектами TASKLIST и TASKITEM.
Рис. 5.12. Структура МД подтипа «Линейный регламент»
Условия выполнения работ описываются объектами LIMIT и REMARKS, которые рассмотрены при описании структуры планового регламента. Объект
TASKITEM описывает одну процедуру технического обслуживания и включает
в себя: TASK – краткое описание (наименование) работы и REFS – ссылку на процедурно-технологический МД, содержащий полное описание процедуры ТО.
Плановый регламент, так же как и линейный регламент, включает в себя перечень
работ, но условия выполнения работ (периодичность) задаются для каждой работы,
а не для всего перечня.
Структура МД для описания планового регламента (SCHEDULE) представлена на рис. 5.13.
Плановый регламент состоит из набора работ (DEFTASK), выполняемых с заданной периодичностью. Включает в себя: TASK – краткое описание (наименование)
работы, REFS – ссылку на процедурно-технологический МД, содержащий полное описание процедуры ТО, LIMIT – описание условия выполнения указанной работы.
219
Объект LIMIT, в свою очередь, включает в себя объекты TRESHOLD (периодичность) и REMARKS (примечания). Периодичность выполнения работ указывается
в заданных единицах (VALUE), например в часах, рабочих циклах и т. д., с допустимыми отклонениями (TOLERANCE).
Рис. 5.13. Структура МД подтипа «Плановый регламент»
МД, содержащие сезонный регламент и регламент обслуживания при хранении, имеют такую же структуру, как и МД планового регламента.
5.12. ПРЕДСТАВЛЕНИЕ ПРОЦЕДУРНО-ТЕХНОЛОГИЧЕСКОЙ ИНФОРМАЦИИ
Процедурно-технологический МД предназначен для описания правил проведения процедур технического обслуживания изделия или его составных частей.
Такие процедуры могут описывать, например, правила монтажа/демонтажа агрегата, работы по очистке/окраске узла и т. п. Процедурно-технологический МД включает в себя три части:
• предварительные требования к ресурсам и инфраструктуре для проведения
работ (PRELREQS);
• операционное описание процедуры технического обслуживания (MAINFUNC);
• перечень работ, выполняемых после завершения процедуры технического
обслуживания (CLOSEUP).
Предварительные требования к ресурсам и инфраструктуре (PRELREQS)
включают в себя (рис. 5.14): ZONE – описание места (зоны), в котором проводится
процедура технического обслуживания, PRODCFG – требования к состоянию изделия перед началом процедуры обслуживания, PERSON – требования к численности и квалификации персонала, SUPEQUIP – перечень оборудования, необходимого для проведения работ, SUPPLIES – перечень расходных материалов,
SPARES – перечень необходимых запасных частей.
Требования к состоянию изделия перед началом выполнения процедуры содержат:
• JACKED – необходимость установки изделия на подъемник.
• SAFEDEV – описание средств защиты персонала от травм и вредных воздействий.
• ELECPWR – необходимость подачи электроэнергии для проведения работ.
220
• HYDPWR – необходимость использования внешнего источника (насоса,
гидроаккумулятора) для работы гидросистем.
• AIRPWR – необходимость использования внешнего источника сжатого воздуха.
• FUEL – необходимость использования источника подачи топлива.
• WATER – необходимость использования источника подачи воды.
• CPOSN – описание положений рычагов управления при проведении обслуживания.
• OPNDURN – расчетное время (в часах), затрачиваемое на проведение процедуры обслуживания.
Рис. 5.14. Упрощенная структура объекта PRELREQS
(предварительные требования)
Требования к численности и квалификации персонала содержат: PERSCAT –
категорию специальности занятого в работе техника, PERSKILL – требования
к квалификации персонала (В – начальный уровень подготовки, I – средний уровень подготовки, А – высокий уровень подготовки), TRADE – код специальности
техника, ESTTIME – расчетную длительность выполнения работ.
221
Следующей частью процедурно-технологического модуля данных является
описание процедуры обслуживания (MAINFUNC) в виде последовательности выполняемых работ (STEP1). Каждая работа, в свою очередь, может быть разбита
на операции (STEP2) и т. д. Описание работы или операции обязательно содержит
основную тексто-графическую часть (элементы PARA, SPECPARA, FIGURE, TABLE) и может включать в себя мультимедиаданные (элемент MMEDIA). Структура
объекта MAINFUNC представлена на рис. 5.15.
Последней частью процедурно-технологического МД является раздел, описывающий работы, выполняемые после завершения процедуры обслуживания
(CLOSEUP). Этот раздел может включать описание действий (STEP1) либо содержать ссылки на другие процедурно-технологические модули (REFS), содержащие
описание этих действий (рис. 5.16). Если специальные завершающие процедуры
не предусматриваются, то этот факт указывается при помощи объекта NOCLOSE.
Рис. 5.15. Структура объекта MAINFUNC (описание процедуры)
Рис. 5.16. Структура объекта CLOSEUP
(завершение процедуры)
222
5.13. ПРЕДСТАВЛЕНИЕ ДАННЫХ О ВОЗМОЖНЫХ НЕИСПРАВНОСТЯХ
В эксплуатационной документации, разрабатываемой в соответствии с АЕСМА 1000D (преимущественно для аэрокосмической техники, оснащенной встроенными средствами технической диагностики), различают три вида неисправностей: локализованные, обнаруженные и наблюдаемые.
Локализованной неисправностью называется отказ оборудования, обнаруженный встроенной системой диагностики, которая при этом однозначно указывает на отказавшее устройство.
Обнаруженной неисправностью называется отказ оборудования, обнаруженный встроенной системой диагностики, которая при этом не может однозначно
идентифицировать отказавшее устройство и указывает на перечень потенциально
неисправных устройств.
Наблюдаемой неисправностью называется неисправность, последствия которой наблюдает технический персонал эксплуатирующей организации, однако
идентифицировать отказавшее устройство не удается. Для его обнаружения необходимо произвести процедуру поиска неисправности.
Процедуры поиска описываются при помощи процедурно-технологических
МД. Для описания перечней перечисленных видов неисправностей используются
три подтипа МД.
1. Перечень локализованных неисправностей представляет собой набор записей (IFAULT), каждая из которых содержит краткое описание и код отказа, выданные встроенной системой диагностики (DESCRIBE), идентификационные данные
устройства, обнаружившего неисправность (DETECT), идентификационные данные отказавшего устройства (LOCANDREP) и примечания (REMARKS). Структура МД данного подтипа представлена на рис. 5.17.
Рис. 5.17. Структура МД, описывающего перечень
локализованных неисправностей
2. Перечень обнаруженных неисправностей представляет собой набор записей
(DFAULT), каждая из которых содержит те же сведения, что и в перечне локализованных неисправностей, но вместо одного отказавшего устройства указывается список
потенциально неисправных устройств (LRUITEM), перечисленных в порядке
уменьшения вероятности их отказа. Для каждого потенциально неисправного устройства приводится ссылка на процедуру его тестирования и проверки (TEST). Структура
МД данного подтипа представлена на рис. 5.18.
223
Рис. 5.18. Структура МД, описывающего перечень обнаруженных неисправностей
Описание потенциально неисправного устройства (LRU) включает в себя:
• NOMEN – наименование устройства;
• IDENTNO – обозначение;
• NSN – номенклатурный номер;
• CSNREF – ссылка на код устройства по каталогу.
3. Перечень наблюдаемых неисправностей представляет собой набор записей
(OFAULT), каждая из которых содержит краткое описание неисправности (DESCRIBE)
с примечаниями (REMARKS), а также описание процедур поиска неисправности
(ISOLATE), которые необходимо выполнить при заданном состоянии изделия
(FCONTEXT).
Рис. 5.19. Структура МД, описывающего перечень
наблюдаемых неисправностей
4. Процедура поиска может включать в себя перечень ссылок (AFIREF) на другие процедурно-технологические МД, а также список потенциально неисправных
устройств (LRUITEM). Структура МД данного подтипа представлена на рис. 5.19.
5.14. СРАВНИТЕЛЬНЫЙ АНАЛИЗ ТЕХНОЛОГИЙ ПРЕДСТАВЛЕНИЯ ДАННЫХ
Сравнительный анализ описанных выше технологий представления данных
показывает, что они имеют много общего и вместе с тем ряд отличий. Обе технологии основаны на идеях объектного подхода и включают в себя языки описания
объектных информационных моделей.
224
Рассмотренные технологии применимы к обеим формам представления информации: в форме электронного документа и в форме базы данных. Однако технология
STEP в большей степени ориентирована на базы данных, а технология SGML –
на электронные документы.
В технологии STEP, ориентированной на задачи, связанные с обработкой больших объемов данных, предусмотрен стандартизованный интерфейс доступа к данным. В технологии SGML предусмотрены средства форматирования данных для их
последующей визуализации и восприятия человеком.
Основные характеристики рассматриваемых технологий и их применимость
для различных форм представления информации приведены в табл. 5.2 и 5.3.
Таблица 5.2
СРАВНЕНИЕ ТЕХНОЛОГИЙ STEP И SGML
Наличие
Язык
стандартиТехнология
описания зованных
представления данных
данных
моделей
данных
Средства
форматирования
данных
для визуализации
Стандартизованный
интерфейс
доступа
к данным
Средства
тестиро- Технология
вания
обмена
и сертифи- данными
кации ИМ
Технология STEP
и ее развитие (РLIB,
MANDATA)
EXPRESS
Да
Нет
Да
Да
Да1
Технология SGML
SGML
Да
Да
Нет
Нет
Да2
Примечание: 1 – Текстовый обменный файл. 2 – Текстовый размеченный файл.
Таблица 5.3
ИСПОЛЬЗОВАНИЕ ТЕХНОЛОГИЙ STEP / SGML
ДЛЯ РАЗЛИЧНЫХ ФОРМ ПРЕДСТАВЛЕНИЯ ИНФОРМАЦИИ
Технологии
Внутреннее
представление
Представление в форме
электронного документа
Представление
в визуализируемой форме
STEP
SGML
В рамках каждой технологии существует комплекс стандартизованных моделей
данных для описания изделий, процессов и ресурсов. Наибольшее число таких моделей разработано в рамках технологии STEP.
В табл. 5.4 приведены результаты анализа существующих моделей данных
для различных объектов и стадий ЖЦ. Как видно из таблицы, модели данных, основанные на технологии STEP, позволяют в основном решать задачи информационного
сопровождения стадий разработки, подготовки производства изделия (протоколы
применения STEP), некоторые задачи интегрированной логистической поддержки
225
и сопровождения процессов эксплуатации (NPDM). Модели в форме SGML Document
Type Definitions используются преимущественно для эксплуатационной документации. Стандартизованные модели MANDATA позволяют решать практически все задачи описания ресурсов.
Таблица 5.4
СТАНДАРТИЗОВАННЫЕ МОДЕЛИ ДЛЯ РАЗНЫХ ТИПОВ ДАННЫХ,
ИСПОЛЬЗУЕМЫХ В ХОДЕ ЖЦ ИЗДЕЛИЯ
ПРОЦЕССЫ
ИЗДЕЛИЕ
Контекст использования данных
РазраПодгоботка
Объект описания
товка
Производ- ЭксплуОбеспечеи проекИЛП
ство
атация
ние качества
произтироваводства
ние
Идентификационные данные АР STEP, NPDM AP STEP, NPDM
APSTEP, NPDM
Состав и структура
АР STEP, NPDM NPDM
NPDM
Геометрические данные
АР STEP
AP STEP
Материалы
Документы
STEP
STEP
АР STEP, NPDM AP STEP
NPDM
SGML
NPDM
NPDM
NPDM
Характеристики
Конфигурация и изменения
изделия
АР STEP, NPDM NPDM
AP STEP, NPDM NPDM
NPDM
NPDM
NPDM
Данные о планируемых
процессах
AP STEP
NPDM
NPDM
AP STEP
NPDM
AP STEP
Данные о выполняемых
процессах
Данные о результатах
выполнения процессов
Данные о случайных
событиях
РЕСУРСЫ
NPDM
Идентификационные данные AP STEP, MAN
DATA
Состав и структура
Характеристики и состояние
MANDATA
AP STEP, NPDM MAN DATA
MANDATA
MANDATA
NPDM
NPDM
NPDM,
MANDATA :
MANDATA
MANDATA
MANDATA
MANDATA
MANDATA
Примечание: AP STEP (Application Protocol STEP) – протоколы применении ISCO 10303
STEP. NPDM (NATO PRODUCT DATA MODEL) – спецификация модели данных НАТО.
MANDATA – ISO 15531. DTD SGML – модели данных, разработанные в форме Document Type
Definitions SGML.
226
5.15. ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ ИЛП
И ФОРМИРОВАНИЕ ЕДИНОЙ ИНФОРМАЦИОННОЙ МОДЕЛИ ИЗДЕЛИЯ
Изучение зарубежного опыта осуществления ИЛП позволяет сделать вывод
о том, что информационное обеспечение ИЛП может быть организовано различными способами, однако в его основу обязательно положен принцип единства
и открытости информационного пространства ИЛП, в рамках которого организуется взаимодействие всех участников проекта. Это возможно только при условии единства информационного представления изделия: необходимо сформировать и поддерживать единую информационную модель в течение всего ЖЦ изделия.
Таким образом, определяется главная задача построения информационного
обеспечения ИЛП и создания единого информационного пространства ЖЦ изделия
или его части. Решать эту задачу следует с помощью CALS-технологий. Чтобы
ИЛП-система удовлетворяла требованиям зарубежных стандартов, можно предложить следующий комплекс мер.
Ход и результаты проектирования изделия должны находиться под контролем
системы управления информацией об изделии (PDM-системы), которая охватывает
все информационное пространство проектирования изделия. Такие системы существуют и у главного конструктора, и у разработчиков отдельных узлов и агрегатов.
Причем необходимо организовать единую систему обмена информацией, включающую PDM-системы всех участников разработки.
Для выработки требований к конструкции изделия, вытекающих из условий
его перспективного функционирования, и к среде эксплуатации следует использовать методы логистического анализа. В России их надо предварительно адаптировать к требованиям отечественных стандартов, прежде всего – в области унификации терминологии.
Сформированные требования к среде эксплуатации изделия в качестве результатов ЛА помещаются в базу данных ЛА, доступ к которой должны иметь все
участники работы по организации ИЛП изделия. При наполнении БД ЛА используются данные PDM-систем (в некоторых случаях БД ЛА бывает частью БД PDMсистемы). При реализации ИЛП потребителю предоставляются отчеты ЛА, которые генерируются из информации БД ЛА, постоянно актуализируемой на основе
данных, получаемых из АСУ эксплуатации изделия потребителя, ведущей электронные досье экземпляров изделия, учет потребления ресурсов поддержки и т. п.
Для непосредственной поддержки эксплуатации создается комплексная система материально-технического обеспечения эксплуатации изделия (КС МТО).
Осуществляется соответствующая настройка АСУП предприятия-эксплуатанта,
заказчика и всех поставщиков, а также организуется система обмена информацией
между ними. Взаимодействие в процессе эксплуатации изделия (собственно функционирование КС МТО) между участниками ИЛП должно быть автоматизировано
путем обмена стандартизированными электронными сообщениями по стандарту
UN/EDIFACT через соответствующие АСУП.
В примере, приведенном на рис. 5.20, последовательность действий по организации поставок предметов МТО такова:
227
228
1. В процессе эксплуатации изделия возникает и может быть идентифицирована потребность в некоторой запчасти.
2. С помощью интерактивного электронного технического руководства
(ИЭТР) и иллюстрированных каталогов запчастей через КС МТО производится
заказ необходимой запчасти у централизованного поставщика в форме обмена
электронными сообщениями.
3. Централизованный поставщик таким же образом осуществляет заказ у подрядчика или соответствующего субподрядчика.
4. Подрядчик обрабатывает и выполняет заказ.
5. Запчасть поступает к централизованному поставщику, и информация
об этом сохраняется в БД АСУП подрядчика и централизованного поставщика.
6. Запчасть пересылается потребителю, и информация об этом сохраняется
в БД АСУП поставщика и потребителя.
7. Через КС МТО запчасть поступает в систему эксплуатации изделия.
Из приведенного примера видно, что роль электронной документации на изделие,
в том числе и интерактивной, в организации ИЛП очень велика. Как уже говорилось ранее, электронная документация на изделие должна создаваться у подрядчиков в соответствии с международной спецификацией на технические публикации,
построенной на основе интегрированной базы данных подготовки технических
публикаций (ИБД ПТП) (CSDB – Common Source Data Base), структура которой
соответствует спецификации АЕСМА S1000D. У каждого подрядчика может быть
собственная ИБД ПТП, данные из нее должны в конечном итоге оказаться в общей
ИБД ПТП проекта. Она формируется с применением языка SGML (ISO8879), так
же как и электронные публикации на ее основе, в том числе ИЭТР, передаваемые
потребителю вместе с изделием.
В качестве примера организации информационного обеспечения ИЛП в России можно привести систему ТРИМ, разработанную НПП «СпецТек», несмотря
на то, что она лишь частично удовлетворяет требованиям стандарта 00-60.
В основу КС МТО в данном случае положена Интернет-технология «электронной торговой площадки». Потенциальные поставщики компонентов изделия
размещают на «торговой площадке» свои прайс-листы, а производитель берет
на себя функцию создания и поддержания единого каталога.
Такая система способна выполнять следующие функции:
• внесение прайс-листов поставщиков в базу данных сервера в соответствии
с каталогом;
• сбор и обработку данных о потребностях производства и клиентов в рамках
заключенных контрактов на очередной период;
• автоматизированный учет уровня цен по основным номенклатурным позициям;
• подготовку и публикацию сводной заявки для доступа поставщиков;
• обеспечение для каждого поставщика (участника торгов), подключенного
к системе, возможности автоматизированной подготовки своей заявки на участие
в торгах (при этом участники торгов, не подключенные к системе, не обязаны регистрироваться в ней и могут готовить свои предложения вручную);
229
• проведение торгов (конкурса) на продукцию, указанную в номенклатурных
позициях сводной заявки;
• заключение контракта с победителем торгов на основе его заявки на участие
в торгах, решения производителя и заявки клиента;
• автоматизированную подготовку всех документов, необходимых для выполнения контрактов и его контроля;
• подготовку и публикацию аналитических отчетов на основе накопленной
в системе статистической информации;
экспорт необходимой информации в другие информационные системы.
Предполагается, что возможность участия в торгах большего количества субпоставщиков, более простая процедура работы с производителем приведут к повышению конкуренции, а значит, к снижению цен. А хранение прайс-листов
на сервере позволит сделать анализ рынка и выбрать наиболее оптимальных поставщиков.
Система состоит из распределенной сети баз данных с прикладным программным обеспечением, сервер которой устанавливается у производителя, а филиалы – у клиентов и субпоставщиков. Связь между ними осуществляется через
сервер таким образом, чтобы на нем была самая полная информация для возможности доступа к ней через www-сервер для тех участников, у которых нет филиальной базы данных. Система имеет внутренний модуль перевода, что позволяет
работать с ней пользователям на любом языке. В системе ТРИМ реализована АСУ
эксплуатации изделия, что до настоящего времени было редкостью на нашем рынке.
5.16. КОНТРОЛЬНЫЕ ВОПРОСЫ
1. Проблемы повышения качества продукции.
2. Задачи, решаемые для повышения конкурентоспособности изделий.
3. Дать понятие интегрированной логистической поддержки (ИЛП).
4. Логистический анализ и его назначение в ИЛП.
5. Охарактеризовать пригодность к поддержке.
6. Назначение материально-технического обеспечения, технического обслуживания и ремонта.
7. Назначение системы ТОиР.
8. Регламент ТОиР изделия.
9. Представление процедурно-технологической информации.
10. Дать пример организации информационного обеспечения ИЛП.
230
6. ЭЛЕКТРОННЫЙ ДОКУМЕНТООБОРОТ
6.1. ЭЛЕКТРОННЫЙ ТЕХНИЧЕСКИЙ ДОКУМЕНТ
Внедрение информационных технологий в процессы делопроизводства и документооборота на предприятиях всех отраслей промышленности требует введения и определения новых понятий, таких как электронный документ, электронный
документооборот, электронная цифровая подпись и т.п.
В январе 2002 г. был принят закон об электронной цифровой подписи,
а в настоящий момент на рассмотрении в Государственной думе находится закон
об электронном документе. Оба закона регламентируют основные понятия, общие
для всех участников электронного документооборота, и являются нормативной
базой для проведения работ в области стандартизации использования электронных
документов в повседневной деятельности физических и юридических лиц с учетом
особенностей выполняемых функций и процессов.
Специфика предприятий, имеющих дело с технической документацией, требует введения термина «электронный технический документ» (ЭТД). ЭТД должен не только отвечать требованиям указанных выше законодательных актов, но
и учитывать действующие системы стандартов – ЕСКД, ЕСТД и ECTПП. С учетом
сформулированных ограничений к настоящему времени разработана общая концепция электронного технического документооборота, где в качестве структурной
единицы рассматривается ЭТД.
Основой изготовления любого изделия является рабочая конструкторская документация (РКД) или конструкторский документ (КД) – документ, который в отдельности или в совокупности с другими документами определяет конструкцию
изделия и имеет содержательную и реквизитную части, в том числе установленные
подписи.
По ГОСТ 2.001-93 (ЕСКД) установлены две равноправные формы представления конструкторской документации (КД) – бумажная и электронная.
К КД отнесены графические, текстовые, аудиовизуальные (мультимедийные)
и иные документы, содержащие информацию об изделии, необходимую для его
разработки, изготовления, контроля, приемки, эксплуатации, ремонта (модернизации) и утилизации.
Реквизит документа – элемент оформления документа, содержащий сведения
о нем. Подпись – реквизит документа, представляющий собой собственноручную
роспись полномочного должностного лица, а для электронных документов – аналог собственноручной росписи – электронная цифровая подпись по ГОСТ 34.310.
Перечень реквизитов устанавливается ГОСТ 2.104.
В 2006 г. введен ГОСТ 2.052-200 ЕСКД. Электронные модели изделия. Общие
положения, в соответствии с которым электронная модель изделия – набор данных, которые вместе определяют свойства, необходимые для изготовления, контроля, приемки, сборки, эксплуатации, ремонта и утилизации изделия. Электронная геометрическая модель – математическая модель, описывающая форму, размеры и иные свойства изделия, зависящие от его формы и размеров.
231
Различают электронные модели детали, сборочной единицы и электронную
структуру изделия. Понятие электронной модели изделия используется как обобщающее понятие для электронной модели детали и электронной модели сборочной
единицы. Электронная структура изделия (ЭСИ) – конструкторский документ, содержащий состав сборочной единицы, комплекса или комплекта, иерархические
отношения (связи) между составными частями и другие данные в зависимости
от его назначения. ЭСИ выполняется только в электронной форме. Для сборочных
единиц, комплексов и комплектов ЭСИ является основным конструкторским документом.
Одной из форм выполнения эксплуатационных документов (преимущественно различных руководств и каталогов) является интерактивный электронный документ.
Виды, комплектность и форму выполнения КД устанавливает разработчик,
если иное не оговорено в техническом задании.
Электронный технический документ – это электронный документ (согласно CALS-технологий электронный документ (ЭД) – это оформленная надлежащим
образом в установленном порядке и зафиксированная на машинном носителе информация, которая может быть представлена в форме, пригодной для ее восприятия человеком), содержащий техническую информацию, которая:
• создается, обрабатывается, хранится и передается с помощью электронных технических средств;
• подписана с соблюдением требований, предусмотренных действующим законодательством;
• может быть представлена в форме, пригодной для восприятия человеком, не обладающим специальными техническими навыками;
• при составлении, хранении, передаче которой использован предусмотренный государственными или международными стандартами либо соглашением
сторон способ, позволяющий достоверно идентифицировать составителя электронного документа.
Электронный технический документ может существовать в виде текстовых
и гипертекстовых файлов, электронных таблиц, файлов базы данных, наборов связанных записей БД, файлов систем САПР, сканированных изображений, видеоизображений и т.д.
В отличие от традиционного документа, характеризующегося только визуальным типом представления, для ЭТД различают:
• внутреннее представление – на машинном носителе или в памяти ЭВМ в виде файла (или набора файлов), в виде записи (или совокупности записей) базы
данных, одновременно записью (или совокупностью записей) базы данных и файлом (или набором файлов);
• внешнее представление в доступном для визуального обозрения виде
и в пригодной для восприятия человеком форме (визуализация на дисплее, двухмерное отображение ЭТД на бумаге, на микропленке).
232
В зависимости от способа использования в процессах обработки и управления
различают два класса ЭТД:
• класс унифицированных ЭТД;
• класс неунифицированных ЭТД.
Унифицированный ЭТД – это ЭТД, имеющий установленный стандартный
шаблон, поэтому внешнее представление унифицированного ЭТД всегда должно
по виду соответствовать формам, регламентированным государственными стандартами (например, текстовые конструкторские документы должны соответствовать ГОСТ 2.106).
Неунифицированный ЭТД стандартного шаблона не имеет, т. е. может принимать любой определяемый разработчиком вид.
В некоторых случаях внутреннее представление ЭТД и его внешнее представление в виде двухмерного отображения могут не иметь полного соответствия – например, в случае гипертекстового документа или трехмерной модели, поэтому
при проведении проектно-конструкторских работ следует устанавливать необходимое и достаточное количество двухмерных отображений ЭТД. Предприятиеразработчик электронной документации должно самостоятельно определить необходимое и достаточное количество двухмерных отображений для каждой формы
и вида ЭТД.
В процессе обращения при работе с ЭТД различают:
• оригинал (подлинник),
• электронную копию,
• твердую копию.
В оригинальном (подлинном) виде ЭТД существует только в автоматизированной системе (АС), в которой данный ЭТД создан. Все зафиксированные на машинном носителе и идентичные друг другу экземпляры ЭТД являются оригиналами с точки зрения информационного содержания.
Электронная копия оригинала – это ЭТД, переданный в другую АС. Аутентичность электронных копий ЭТД обеспечивается идентичностью программнотехнического обеспечения обменивающихся сторон или оговаривается в договоре или иной форме соглашения.
Твердая копия ЭТД – это двухмерное отображение ЭТД, которое обладает
всеми характеристиками этого ЭТД, обусловленными целью выпуска ЭТД и возможностями задействованных при его создании электронных технических средств,
или только теми характеристиками ЭТД, которые оговорены в договоре или другой форме соглашения. Твердая копия ЭТД, подписанная в установленном порядке
собственноручно владельцами соответствующих ЭЦП или уполномоченными
на это лицами, обладает статусом подлинника документа, оригиналом которого
является ЭТД. Твердая копия должна содержать указание на то, что оригиналом
является ЭТД.
На всех стадиях ЖЦ продукта, процесса или системы оригинал ЭТД и его
подлинник, выполненный на немашинном носителе информации, имеют одинаковый статус.
233
6.2. СИСТЕМА АВТОМАТИЗАЦИИ ДОКУМЕНТООБОРОТА
С одной стороны, термин «система автоматизации документооборота» можно
трактовать как отражение термина «делопроизводство», достаточно хорошо формализованного в традиционном управлении, при использовании его в компьютерной индустрии. В этом случае средства автоматизации документооборота сводились бы к компьютеризации традиционных задач делопроизводства – формированию дел и учету содержащихся в них документов, контролю исполнения
и формированию соответствующей отчетности.
Другим способом трактовки этого термина является нахождение его аналогов
в западной компьютерной индустрии. К сожалению, подобного термина, однозначно соответствующего отечественному «документообороту», в западном
компьютерном словаре не имеется. В зависимости от пристрастий и специфики
описываемого программного продукта в литературе и прессе можно встретить
следующие соответствия между термином «система автоматизации документооборота» и западными терминами:
• DMS (Document Management Systems). В русскоязычной литературе
для данного термина имеется более точный перевод – «Архивы документов».
• DocFlow – системы документов или системы маршрутизации документов.
• WorkFlow-системы. Более точно данный термин переводится как «Системы автоматизации бизнес-процессов».
В последнее время в прессе появились новые термины, близкие теме автоматизации документооборота: Document Warehousing (хранилища документов)
и Knowledge Management (управление знаниями). Системы данного класса являются дальнейшим развитием систем документооборота и необходимы для структуризации и долгосрочного хранения больших массивов, накопленных в организации
документов, а также для оптимального поиска необходимой информации на массиве разнородных накопленных документов.
Система автоматизации документооборота – достаточно сложный механизм.
Очевидно, не имеет смысла говорить об отдельном программном продукте как
о системе автоматизации документооборота организации. Система автоматизации
документооборота может по-разному интерпретироваться в зависимости от размера организации и специфики ее деятельности. Например, системы автоматизации
документооборота небольшой торговой организации, законодательного собрания
и проектной организации будут выполнять различные функции, строиться на различных программных продуктах и вообще иметь мало общего. Однако можно выделить ряд общих функций, присущих таким системам.
Система автоматизации документооборота складывается из нескольких подсистем. Каждая подсистема обладает набором специфических для нее функций.
При этом отдельные подсистемы тесно взаимодействуют между собой. Разделение
системы документооборота на подсистемы носит несколько «академический» характер.
Можно выделить следующие подсистемы автоматизации документооборота:
234
• Системы автоматизации делопроизводства. В их функции входит фиксация документов в специальной базе данных, выражающаяся в заполнении специальной карточки документа. Содержимое карточки документа может варьироваться в зависимости от сложившейся в организации ситуации. Сами документы хранятся в бумажном виде в специальном архиве, но в базе данных отображается их
текущее местоположение и статус, включая атрибуты контроля исполнения.
• Архивы документов. Архив документов – это то, что собственно хранит
электронный документ. При этом может храниться либо образ документа, либо его
содержание, либо и то и другое. Помимо собственно хранения документов архив
должен обеспечивать навигацию по иерархии документов и их поиск.
• Системы ввода документов и системы обработки образов документов.
В функции таких подсистем входит перевод документов из бумажного вида в электронный.
• Системы маршрутизации документов. Занимаются непосредственно пересылкой документов на рабочие места исполнителей, сбором информации о текущем статусе документов, осуществляют консолидацию документов по завершении работы с ними на отдельных этапах, а также обеспечивают средства доступа
к информации о текущем состоянии работ с документами.
Каждая система автоматизации документооборота является подмножеством
вышеперечисленных подсистем.
Рассмотрим реализацию рассмотренной выше абстракции «документ» в различных системах автоматизации документооборота:
• Бумажный документ представляет собой объект, который непосредственно
не погружен в информационную систему, но о котором в ней имеется та или иная
информация. Разновидностью данного типа документа может быть фотографическая копия документа, микрофиш, изображение, видеозапись и пр.
• Электронный образ документа – копия документа (результат сканирования), хранящаяся в информационной системе. Образ документа помимо собственно изображения документа, представляющего собой файл в том или ином формате,
может содержать некоторый набор свойств, его идентифицирующих (название,
категорию, дату создания и пр.) При этом данная информация хранится не непосредственно в файле образа документа, а в некоторой внешней по отношению
к нему базе данных.
• Электронный документ в отличие от образа документа внутри себя имеет
содержательную информацию, которая может быть использована, например, для
поиска документа или отнесения его к той или иной группе. Например, это может
быть текст или электронная форма Microsoft Word, таблица Excel, сообщение
в формате электронной почты Internet. Файлы документов могут быть «сырыми»,
т. е. не содержащими внутри себя структурных элементов (обычные текстовые документы), или структурированными. Последние внутри себя содержат элементы
структуры, позволяющие внешним приложениям получать информацию об отдельных элементах информации (формы Word, электронные таблицы, документы
в формате XML). Еще одной разновидностью данной группы документов являются
файлы составных документов, например файлы Binder Microsoft Office.
235
• Записи баз данных специализированных систем автоматизации групповой
работы, таких как документы Lotus Notes или электронные формы Microsoft
Exchange. В отличие от обычного электронного документа, данный документ
не представлен в виде отдельного файла, но представляет собой некоторую целостную единицу информации, имеющую уникальный идентификатор, средство отображения и модификации. Данный тип документов может быть извлечен из системы и передан, например, посредством электронной почты в другое подразделение
и снова погружен в систему. В силу природы приложений документы данного типа
изначально содержат внутреннюю структуру и могут содержать внутри себя другие файлы документов или ссылки на них.
• Отчеты, порождаемые в результате работы прикладных автоматизированных рабочих мест (АРМ). Это особый тип документов, динамически формируемых из различных записей различных баз данных. После просмотра или вывода
на печать данный документ перестает существовать как целостный объект в информационной системе. Данный документ «живет» только в пространстве конкретного приложения и не может отчуждаться от него. Например, для передачи
в другое подразделение он должен быть преобразован в документ одного из вышеперечисленных типов.
Выбор одного из вышеперечисленных типов зависит от сложившейся структуры документооборота предприятия и задач, поставленных перед системой.
В России разработаны государственные стандарты, которые ориентированы
на поддержку международных стандартов (ISO 9000, CALS, STEP), что делает
электронный документооборот открытым для международного сотрудничества:
• ГОСТ Р 34.10-94 – Информационная технология. Криптографическая защита информации. Процедура выработки и проверки электронной цифровой подписи
на базе асимметричного криптографического алгоритма.
• ГОСТ Р 34.11-94 – Информационная технология. Криптографическая защита информации. Функция хэширования.
• ГОСТ Р 50739-95 – Средства вычислительной техники. Защита от несанкционированного доступа к информации. Общие технические требования.
Предлагаемое решение служит для автоматизации документооборота, как договоров, так и всей технической документации: от ввода информации с бумажных
носителей, ее редактирования и обработки до помещения ее в архив и получения
твердой копии. Оно включает в себя все необходимые средства для управления
информацией об изделии или проекте на протяжении всего жизненного цикла, как
того требуют CALS-технологии и стандарты серии ISO 9000.
Применение данного решения дает следующие выгоды:
• использование электронной цифровой подписи (ЭЦП), обеспечивающей защиту от подделки;
• обеспечение защиты содержимого документа, т. к. при изменении
содержимого нарушается целостность ЭЦП;
• открытость системы документооборота для передачи документации на другие предприятия, в том числе зарубежные;
236
• экономию времени обработки документов, начиная от органа управления
к органу исполнительному и обратно, т. к. использование новых технологий и специализированного программного обеспечения приводит к ужесточенному контролю о прочтении, ознакомлении;
• экономию оборудования и связанных с ним расходов на обслуживание, т. к.
уменьшается число копировального оборудования и оборудования, предназначенного для сканирования документов;
• уменьшение количества персонала. Уменьшение вызвано отсутствием необходимости лишнего числа архивариусов и другого персонала, связанного с процессом предыдущего документооборота.
6.3. ЭЛЕКТРОННАЯ ЦИФРОВАЯ ПОДПИСЬ
Электронная цифровая подпись – это неотъемлемая часть электронного документа, предназначенная для удостоверения информации, составляющей содержательную часть ЭД, и подтверждения его подлинности и целостности.
Под подлинностью понимается подтвержденное авторство создателя документа, что определяется принадлежностью электронной подписи конкретному физическому лицу. Электронная цифровая подпись (ЭЦП), удостоверяющая подлинность документа, представляет собой функцию содержимого документа (hash
или хэш-функцию), рассчитываемую по определенному алгоритму и закодированную с помощью секретного (закрытого) ключа автора документа. Прочитать ЭЦП
можно с помощью открытого (несекретного) ключа, однако «подделать» подпись
невозможно, поскольку закрытый ключ потенциальному злоумышленнику неизвестен. При использовании документа подсчитывается его хэш-функция и сравнивается с ЭЦП, присоединенной к документу. Следовательно, если в документ были
внесены несанкционированные изменения, то они обнаруживаются, т. к. хэшфункция документа перестанет совпадать с ЭЦП.
Под целостностью ЭД понимается тот факт, что после его создания и заверения подписью в его содержание не вносилось никаких изменений.
ЭЦП представляет собой набор знаков, генерируемых по определенному алгоритму. ЭЦП является функцией от содержимого подписываемого электронного
документа и секретного ключа автора. Секретный ключ (код) имеется у каждого
субъекта, имеющего право подписи, и может храниться на дискете или смарткарте. Второй ключ (открытый) используется читателями (получателями) документа для проверки подлинности ЭЦП, сопровождающей документ. При помощи
ЭЦП можно подписывать отдельные файлы или фрагменты баз данных (поля, записи и т. д.). В последнем случае ПО, реализующее ЭЦП, должно встраиваться
в прикладные автоматизированные системы. Общий алгоритм применения ЭЦП
приведен на рис. 6.1.
Электронная цифровая подпись жестко связывает в одно целое содержание
документа и идентификацию подписывающего лица и делает невозможным изменение документа без нарушения подлинности данной подписи, т. е. исключается
подделка документа.
237
верно/неверно
Рис. 6.1. Общий алгоритм применения ЭЦП
Несколько подписей можно использовать последовательно или параллельно.
Любая ЭЦП, подтверждающая документ после предыдущих подписей, обеспечивает проверку целостности по предыдущим подписям.
Атрибуты записи ЭЦП закодированы. Минимальное количество ЭЦП для каждого ЭД должно определяться требуемыми реквизитами унифицированной формы представления документа. Количество ЭЦП для ЭД, не имеющего унифицированной формы представления, устанавливается на предприятии.
Подтверждение подлинности и целостности ЭД производится путем применения электронной цифровой подписи, произведенной специальными программнотехническими средствами.
В составе автоматизированной информационной системы, в рамках которой
происходит создание, обработка и хранение электронных документов, используются программные и технические средства, в том числе и криптографические,
обеспечивающие необходимый уровень их защиты.
Электронная цифровая подпись является аналогом физической подписи, т. е.
обладает двумя основными свойствами:
• воспроизводима только подписывающим лицом, а подлинность ее может
быть проверена и удостоверена многими;
• неразрывно связана с содержанием конкретного документа и только с ним.
Последовательно ЭЦП используется в случае, когда необходимо иметь информацию о порядке прохождения документа по инстанциям (например, в процессе согласования и утверждения). Параллельно ЭЦП используется в случае, когда
238
достаточным является констатация факта ознакомления с документом, а информация о последовательности ознакомления лиц с содержанием документа не требуется.
Система поддерживает различные платформы: MS Windows 95/98/2000/ME/NT,
Novell NetWare и др. Используя PDM систему, можно удовлетворить все эти требования.
6.4. СТРУКТУРИРОВАНИЕ ИНФОРМАЦИИ В ЭТД
На сегодня в РФ действуют ГОСТы, поддерживающие CALS-технологии. Эти
стандарты распространяются на все виды документов, изготовляемых, хранимых
и применяемых в электронном виде.
Для управления разработкой, внешним и внутренним представлением, модификацией, обменом, хранением и поиском ЭТД содержащаяся в ЭТД информация
структурируется, т. е. представляется в виде совокупности объектов, называемых
частями ЭТД. Различают физическую структуру и логическую структуру ЭТД.
Физическая структура влияет на внешнее представление ЭТД и, более того,
практически определяет ее. Состав физической структуры ЭТД зависит от вида
ЭТД и от представленной в этом ЭТД информации. Любой ЭТД имеет две физических структуры: контентную и макетную.
Контентная структура ЭТД рассматривает его части в соответствии со смысловым значением информации ЭТД – главами, разделами, рисунками и абзацами.
Макетная – в соответствии с вопросами представления внешней формы, например страницами.
Контентная и макетная структуры являются альтернативными, но дополняющими друг друга формами одного и того же ЭТД.
В отличие от физической структуры, логическая структура ЭТД используется при хранении, обработке, обмене и управлении внутренним представлением
ЭТД в системе управления электронной технической документацией. Логическая
структура состоит из четырех частей:
• идентификационной,
• административной,
• исторической,
• содержательной.
Идентификационная часть содержит идентификационные данные и признаки
ЭТД (обозначение, наименование документа, дата выпуска, литера, регистрационный
номер и т. п.).
Административная часть – аутентификационные данные и признаки ЭТД
и структурные характеристики ЭТД (информация об ЭЦП, алгоритм хеширования
и подписи, сведения о количестве листов документа и т. п.).
Историческая часть содержит данные о внесенных в ЭТД изменениях. Идентификационную, аутентификационную и историческую части обобщенно называют
реквизитной частью ЭТД.
Содержательная часть ЭТД состоит из произвольного количества информационных единиц, представляющих содержание ЭТД. Все элементы логической
структуры ЭТД могут по-разному обрабатываться и храниться в АС.
239
В реквизитной части после заголовка следуют записи, содержащие информацию о примененных электронных подписях и шифровании (аутентификационный
блок), затем идентификационные признаки документа и далее дополнительная информация о документе в произвольном порядке (идентификационный блок).
Содержательная часть ЭД следует за реквизитной частью и состоит из набора
информационных единиц, непосредственно представляющих собственно содержание документа.
В зависимости от организации связей между реквизитной и содержательной частями (рис. 6.2) ЭТД делятся на простые, сложные и комплектные.
Простой электронный технический документ – ЭТД, содержательная часть которого физически реализована в виде одной информационной единицы.
Рис. 6.2. Логическая структура простого ЭТД
Сложный электронный технический документ – ЭТД, содержательная часть
которого реализована в виде нескольких информационных единиц.
Сложный ЭТД (рис. 6.3) состоит из общей части, включающей в себя единую
для всех входящих информационных единиц реквизитную часть и необязательную
содержательную часть, и совокупности информационных единиц. Каждая входящая
информационная единица имеет собственный идентификатор, который позволяет
в единой реквизитной части сложного ЭТД устанавливать взаимосвязи между информационными единицами на стадиях жизненного цикла ЭТД при различных типах внутренней формы представления ЭТД.
Комплектный ЭТД (рис. 6.4) состоит из главного ЭТД и совокупности подчиненных ЭТД, имеющих единое целевое назначение и логически связанных друг
с другом. Главный ЭТД включает единую для всех подчиненных ЭТД реквизитную
часть, содержащую атрибуты ЭТД в целом и (необязательно) общую содержательную часть. Каждый подчиненный ЭТД обязательно включает собственную реквизитную и содержательную части. Связь между главным ЭТД и подчиненными ЭТД
осуществляется через ссылки на их реквизитные части.
Примером комплектного ЭТД является набор ЭТД, представляющих комплект технической документации на этапе рабочего проектирования. Номенклатура документов в комплекте может определяться ГОСТ 2.102-68 или указываться
в договоре или иной форме соглашения. Каждый отдельный ЭТД в составе комплектного ЭТД может управляться АС по собственной реквизитной части независимо
240
от другого при сохранении условий комплектности. Внутри ЭТД информационная
связь осуществляется по реквизитным частям, между содержательными частями
информационная связь отсутствует.
Рис. 6.3. Логическая структура сложного ЭТД
Рис. 6.4. Логическая структура комплектного ЭТД
ЭД сохраняет статус официального документа при передаче из одной АС
в другую, при условии, что последняя имеет возможность проводить обработку
ЭЦП, что и обеспечивает возможность международного конфиденциального обмена информацией.
При использовании различных АС обеспечиваются одновременные уведомления об абонентах систем, касающиеся принадлежащих им ЭЦП. Невозможность
241
удостоверения принимающей АС хотя бы одной ЭЦП, представленной в документе, снимает с документа статус официального. Приобретаемый им в этом случае
статус регламентируется договором или иной формой соглашения.
Вся работа с ЭД ведется с оригиналом (требует использования его общей части без ее модификации) или с электронной копией (требует модификации общей
части с целью порождения другого документа). Для архивных целей (целей резервного копирования) используется оригинал ЭД.
Копия общей части ЭД, выполненная любыми способами, кроме средств АС,
не является официальным документом. Она может создаваться и использоваться
в рабочем порядке, который определяется на предприятии, использующем документацию в виде ЭД.
В настоящее время существует множество систем, решающих задачи организации документооборота предприятия-заказчика. Однако подходы к решению
и концепции построения таких систем имеют некоторые различия. В число определяющих факторов входят:
• Масштаб предприятия.
• Сложившаяся на предприятии структура документооборота.
• Требования предприятия к системе.
6.5. ЖИЗНЕННЫЙ ЦИКЛ ЭТД
Жизненный цикл ЭТД состоит из следующих стадий:
• создание ЭТД (создание реквизитной и содержательной частей ЭТД, формирование физической структуры в соответствии с ГОСТом для внешнего
представления ЭТД);
• выпуск ЭТД;
• обращение ЭТД (распространение, использование, просмотр, анализ
содержательной части, подготовка предложений по внесению изменений);
• внесение изменений в ЭТД;
• изъятие ЭТД из обращения (помещение в архив на хранение);
• уничтожение ЭТД (удаление всех данных реквизитной и содержательной
частей ЭТД).
На протяжении жизненного цикла все ЭТД характеризуются номером версии
и номером итерации (рис. 6.5). Версия ЭТД – это представление ЭТД с обозначением данного ЭТД, которое является самостоятельной единицей в процессе управления электронной технической документацией, т. е. ЭТД не существует сам
по себе – существует определенная нумерованная версия ЭТД. Начиная с момента
создания ЭТД версии ЭТД нумеруются последовательно, начиная с 1. Каждая версия имеет свой жизненный цикл, стадиями которого являются:
• создание версии ЭТД;
• разработка версии ЭТД;
• согласование и утверждение версии ЭТД;
• выпуск версии ЭТД;
• обращение версии ЭТД;
242
• изъятие из обращения версии ЭТД;
• уничтожение версии ЭТД.
В целях облегчения управления жизненным циклом версия ЭТД должна обладать статусом. Статус версии ЭТД представляет собой краткое описание состояния
версии в данный момент времени.
Рис. 6.5. Связь ЖЦ ЭТД и ЖЦ версий ЭТД
Устанавливаются обязательные статусы версии ЭТД:
• версия создана;
• версия разработана;
• версия согласована;
• версия утверждена/не утверждена;
• версия выпущена.
Названия, порядок и условия присвоения других статусов версии ЭТД определяются каждым конкретным предприятием отдельно. Для отслеживания изменений, вносимых в версию ЭТД до присвоения ей следующего статуса, используется
понятие «итерация версии ЭТД». Для каждого статуса версии ЭТД итерации нумеруются последовательно, начиная с 1.
Каждая версия ЭТД создается с определенным множеством целей выпуска.
ЭТД считается выпущенным, если последняя версия ЭТД удовлетворяет всем целям выпуска ЭТД. Выпущенному ЭТД присваивается нулевой номер версии ЭТД,
при этом все предыдущие версии ЭТД уничтожаются. При внесении изменений в
ЭТД ему опять присваивается номер версии, отличный от нуля.
Версии ЭТД выпускаются последовательно до тех пор, пока последняя выпущенная версия не будет объявлена нулевой версией ЭТД. Все выпущенные версии
характеризуются применимостью, которая указывает на актуальность версии ЭТД.
В зависимости от порядка вступления в действие разных версий одного и того же
ЭТД различают последовательную и параллельную применимость (рис. 6.6).
243
Последовательная применимость подразумевает, что в каждый момент времени на протяжении всего ЖЦ ЭТД существует только одна применимая версия –
последняя по времени выпуска версия ЭТД, т. е. новая версия ЭТД должна всегда
заменять предыдущую версию этого же ЭТД. При создании новой версии ЭТД
должны быть установлены двухсторонние ссылки («заменен/заменен на») между
предыдущей версией ЭТД и новой версией ЭТД, указывающие на то, что идентификационные данные предыдущей версии ЭТД заменяются идентификационными
данными новой версии ЭТД, и новая версия ЭТД заменяет старую версию ЭТД.
Все версии ЭТД, изъятые из применения, должны быть помещены в архив до выпуска нулевой версии ЭТД.
Параллельная применимость подразумевает, что все выпущенные версии ЭТД
являются применимыми, т. е. новая версия ЭТД не заменяет автоматически предыдущие версии этого же ЭТД. Каждая новая версия ЭТД основывается на предыдущей версии ЭТД и имеет определенную цель выпуска, для которой используется
именно указанная версия. Если какая-либо применимая версия ЭТД имеет такую
же цель выпуска, что и новая выпущенная версия ЭТД, то либо изменяется цель
выпуска старой версии ЭТД, либо старая версия ЭТД изымается из применения
и помещается в архив до выпуска нулевой версии ЭТД.
В случае параллельной применимости двухсторонние ссылки («заменен/заменен на») между какой-либо применимой версией ЭТД и новой версией
ЭТД должны устанавливаться только в случае изменения цели выпуска существующей применимой версии.
При параллельном проектировании различные соисполнители используют
при решении параллельных задач информацию, внесенную в еще не выпущенные
ЭТД. По этой причине актуальна проблема идентификации разрабатываемого ЭТД
в системе управления электронной технической документацией. Введение показателя «степень готовности ЭТД к публикации» позволяет характеризовать состояние ЭТД посредством выпущенных версий данного ЭТД (рис. 6.7).
244
Достижение ЭТД очередной степени готовности к публикации означает утверждение и выпуск версии ЭТД с определенной целью выпуска. Количество целей
выпуска ЭТД устанавливается по усмотрению каждого конкретного предприятия.
После достижения ЭТД готовности ко всем целям выпуска, т. е. после выпуска последней версии, ЭТД направляется на внешнее утверждение. В случае принятия внешними организациями решения об отклонении ЭТД создается новый ЭТД,
и цикл выпуска версий ЭТД проводится заново.
6.6. ОСНОВНЫЕ ПРИНЦИПЫ ОРГАНИЗАЦИИ КАНЦЕЛЯРСКОЙ РАБОТЫ
Практически на всех предприятиях, особенно на предприятиях государственного подчинения, существуют общие отделы. Их название варьируется – это может быть отдел общего делопроизводства, общий отдел, управление делами и т. д.,
но самое главное – суть данного подразделения остается одинаковой на всех предприятиях независимо от названия, и заключается она в организации потоков документов на данном предприятии (приказов, распоряжений, поручений, писем и т. д.).
Рассмотрим основные виды документов, атрибутику документов, потоки документов и работы, используемые в работе данных подразделений. Кроме центрального документооборота крупного предприятия существует специализированный документооборот (в подразделениях предприятия в отделах специализированного делопроизводства и т. д.).
В данном подразделе перечислены основные принципы организации устойчивого и управляемого документооборота для организации. Все они изложены в ли245
тературе и известны практически любому руководящему работнику, но, как показывает практика, они достаточно часто нарушаются.
Основным принципом документооборота является то, что ни у кого не существует локальных архивов документов. Любой входящий документ, не попавший
в общий архив документов, является потенциальным клиентом на неисполнение.
В организации есть соответствующая служба, а именно канцелярия, которая отвечает за прохождение документов. Документы, не учтенные в канцелярии, теряются
чаше всего.
В организации должен существовать только один канал поступления входящих документов. Даже если прием документов построен по распределенной схеме,
то это сделано только для повышения скорости обработки документов. Все такие
подразделения мгновенно предоставляют информацию в канцелярию (желательно
в режиме онлайн связи с канцелярией). Можно рассматривать, что такие удаленные пункты регистрации документов являются подразделениями канцелярии.
Для создания полноты картины документооборота на предприятии система
документооборота не должна заканчиваться на ответственных исполнителях, т. е.
система автоматизации документооборота организации не должна замыкаться
только на канцелярии, а должна иметь продолжение в системах управления документооборотом подразделений организации.
6.7. ТИПЫ ДОКУМЕНТОВ, КЛАССИФИКАЦИЯ И ИХ ВЗАИМОСВЯЗИ
Рассмотрим основные типы документов, используемые в работе предприятия
с их характеристиками. Типов документов, используемых в работе предприятия,
достаточно много (на отдельных предприятиях их число доходит до 500–600).
В то же время с точки зрения канцелярии основных видов документов бывает
весьма небольшое количество, а именно 3 вида:
• Входящие. Это документы, которые поступили на предприятие от внешних
партнеров. Большинство входящих документов должно порождать соответствующие исходящие, причем в заранее установленные сроки. Сроки устанавливаются
или нормативными актами, предписывающими то или иное время ответа на соответствующий входящий документ, или сроком исполнения, указанным непосредственно во входящем документе.
• Исходящие. Большинство исходящих документов является ответом организации на соответствующие входящие документы. Некоторая часть исходящих документов готовится на основе внутренних документов предприятия. Небольшое
число исходящих документов может требовать поступления входящих документов
(например, запросы в сторонние организации типа: «Прошу дать справку по вопросу в срок до …»).
• Внутренние. Данные документы используются для организации работы
предприятия. Через канцелярию проходят не все внутренние документы, а только
переписка наиболее крупных структурных подразделений предприятия (особенно
если они территориально разнесены) и приказы руководства предприятия. Также
246
через канцелярию проходят внутренние документы, порождающие исходящие.
В частности, по общим правилам делопроизводства единственный способ отправить запрос, письмо или материалы во внешнюю организацию – это направить
внутренний документ в канцелярию, где его преобразуют в исходящий и отправят
в стороннюю организацию.
Документы каждого из этих видов могут быть достаточно разнообразны. Это
могут быть письма, распоряжения, циркулярные указания и т. д. Обычно под типом документа на предприятии понимается именно эти деления, причем еще более
детализованные (допустим, если письма, то чему посвященные – жалобы, предложения, пожелания и т. д.). С точки зрения канцелярии данное деление достаточно
неинтересно, хотя во внутренней полной системе делопроизводства оно безусловно необходимо. Далее здесь будут рассматриваться только канцелярские виды документов – входящие, внутренние и исходящие.
Прежде всего, все документы, проходящие через общий отдел, обладают уникальным регистрационным номером (возможны свои алгоритмы построения номеров для каждого из типов документов). Мало того, любая бумага, не имеющая регистрационного номера – это просто бумага, а не документ. Документом ее делает
именно наличие на ней регистрационного номера.
Введем следующие понятия:
• Документооборот – движение документов в рамках документационного
обеспечения управления. Иначе говоря, документооборот – это совокупность процедур, обеспечивающих движение документов с момента их создания или поступления до завершения, исполнения или отправки. Путь, по которому проходит движение документа, называется маршрутом.
Таким образом, из определения понятия документооборота можно выделить
две сущности, относящиеся к данной предметной области: документ и маршрут.
Взаимосвязь этих сущностей определяется наличием у каждого документа некоторого маршрута.
Разберем каждую из выявленных сущностей подробнее.
Документ – слабоструктурированная совокупность блоков или объектов информации, понятная человеку. Жизненный цикл каждого документа состоит из
трех основных стадий: создание, утверждение (подпись, согласование и т. д.), исполнение (закрытие).
Маршрут – путь документа от этапа создания или поступления до этапа завершения, исполнения или отправки. Это определение требует некоторого уточнения. Каждый шаг на этом пути – этап утверждения документа некоторым должностным лицом согласно существующим правилам. (Например, для утверждения документа должностное лицо должно обладать достаточными правами.)
Таким образом, выделим еще 2 сущности системы документооборота:
• Должностное лицо.
• Правило.
Таким образом, маршрут, соответствующий некоторому документу, есть список должностных лиц в порядке, установленном некоторыми правилами.
247
В результате мы получили следующий список абстракций области документооборота:
• Документ.
• Маршрут.
• Должностное лицо.
• Правило.
Очевидно, что все системы автоматизации документооборота построены
на основе этих абстракций. Для построения собственной системы полезно также
рассмотреть множество реализаций данных абстракций в существующих системах.
6.8. ОБЩИЕ АТРИБУТЫ ДОКУМЕНТОВ
Атрибуты документов у каждого партнера весьма разнообразны. В то же время можно выделить общую часть атрибутов, которые встречаются практически
во всех организациях. Причем эти общие атрибуты несколько различны у всех типов канцелярских документов.
Основными атрибутами канцелярского документа являются:
1. Регистрационный номер документа. Данный номер однозначно позволяет
сослаться на документ, прошедший через канцелярию. Структура регистрационного номера может быть различна для исходящих, входящих и внутренних документов. Структура регистрационного номера определяется в каждой организации самостоятельно.
2. Источник документа (контрагент). Указывает, откуда получен документ.
Для входящих документов это сторонняя организация, для внутренних и исходящих документов это или подразделение, или конкретное лицо из руководства
предприятия.
3. Ответственный исполнитель документа. Указывает сотрудника предприятия, которому поручено исполнение данного документа или который разработал
данный документ (для исходящих и внутренних). Исполнитель документа всегда
один и только один. Иногда встречаются два исполнителя документа (для документов длительного исполнения при смене кадрового состава предприятия).
4. Код документа по номенклатуре дел предприятия. Данный атрибут относит
документ к тому или иному кругу типовых вопросов, решаемых предприятием в
своей производственной деятельности. Номенклатура дел – это формальный список дел предприятия, который утверждается заранее на определенный период времени (обычно на год). Ранее данная номенклатура являлась достаточно статичной,
в современных условиях номенклатура дел является высоко динамичным документом, который может обновляться 1–4 раза в год.
6.9. АТРИБУТЫ, ЗАВИСЯЩИЕ ОТ ТИПОВ ДОКУМЕНТА
Далее в документах могут быть атрибуты, специфические для данного типа
документа.
• Входящие документы имеют кроме базовых атрибутов еще:
248
– Контрольный срок исполнения. Данный атрибут берется или непосредственно из входного документа (где он может быть указан) или из типа входного документа, который определяет сроки ответа на те или иные входные документы.
– Контролирующее лицо. Обычно это одно из первых лиц предприятия, которое назначает конкретного исполнителя документа ставить резолюцию «Об исполнении доложить». Данный атрибут проставляется не на всех входящих документах, а только на наиболее важных, ответственных. Непустой аргумент вызывает
необходимость в случае завершения обработки документа посылать сообщения
о прохождении документа соответствующему субъекту.
• Внутренние документы помимо стандартных атрибутов могут обладать еще
следующими:
– Список подразделений предприятия для ознакомления.
– Контрольный срок ознакомления или исполнения.
– Список исполнителей документа.
• Исходящие документы имеют следующие дополнительные атрибуты:
– Документ-основание. Этот атрибут есть всегда, т. к. исходящий документ
всегда порождается на основе или входящего, или внутреннего.
– Список рассылки.
– Контрольный срок ответа. Данный атрибут встречается редко и не во всех
организациях.
В конкретных организациях данные атрибуты могут носить различные наименования или пополняться дополнительными атрибутами, часто большим количеством. Но перечисленные выше атрибуты присутствуют во всех канцеляриях
предприятий.
6.10. ВЗАИМОСВЯЗИ ДОКУМЕНТОВ
Все документы, проходящие через канцелярию, являются связанными документами, в том смысле, что большинство из них ссылается на другие документы.
Наиболее типичным случаем является входящий документ, который практически
всегда порождает соответствующий ему исходящий.
Без связей как таковых могут появляться только внутренние и входящие документы. Причем входящие документы могут иметь связи как на исходящие, которые вызывают их появление, так и на другие входящие (см. «Процесс согласования
или уточнения ответа» на рис. 6.8). Все документы связаны как в системе управления документами, так и в системе контроля исполнения (как принадлежащие одной работе). В этом смысле здесь наблюдается некоторое дублирование связей.
249
Рис. 6.8. Взаимосвязи документов в канцелярии
Связи в большинстве случаев направлены по принципу: «главный – подчиненный». Иногда встречаются ненаправленные связи, которые объединяют родственные документы (документы, посвященные одному вопросу).
6.11. ТИПОВЫЕ ПРОЦЕССЫ КАНЦЕЛЯРИИ
В данном подразделе переходим от великой статики к динамике документов,
т.е. вместе с рассмотрением самих документов приступаем к рассмотрению процессов обработки документов. Основным процессом канцелярии является прохождение по предприятию входных документов. Канцелярия отвечает за сроки исполнения входных документов, точнее, выполняет фискальные функции: кто и когда
задержал выполнение документа. При этом существует два основных маршрута
прохождения документа:
1. Непосредственно исполнителю (рис. 6.9).
2. На принятие решения в центральный аппарат (рис. 6.10).
Причем первый маршрут означает то, что почти наверняка этот документ будет поставлен на контроль. В то же время не следует путать со вторым маршрутом
документы, которые поступают на исполнение в центральный аппарат предприятия (например, если на циркулярном письме стоит «Директорам предприятий…»). Такие документы (поступающие на исполнение в центральный аппарат)
характеризуются тем, что ответственным исполнителем для них является один
из директоров предприятия (или их замов).
250
Для документов, проходящих по второму маршруту, ответственным исполнителем является кто-то из руководителей среднего звена, а директорат осуществляет
контроль за результатами работы (а то и этого не делает).
Рис. 6.9. Процесс прямой обработки входящего документа: на входе этого процесса –
входящий документ; на выходе – проект исходящего, который проходит через канцелярию и становится реальным исходящим после регистрации
Рис. 6.10. Схема обработки документа с контролем директора:
на входе этого процесса – входящий документ
По существующей практике работы канцелярий крупных организаций на контроль ставятся только дела, проходящие по второй схеме. Причем, как известно
из жалоб работников канцелярий, дела, проходящие по первой схеме, часто «провисают», т. е. теряются в ходе обработки. Если в дальнейшем кому-то из директоров придет в голову получить информацию о таком деле, то в канцелярии возникают достаточно большие проблемы.
Значительная часть проблем канцелярии возникает из-за того, что она обязана
контролировать только ответственных исполнителей, а не полную цепочку обработки документа. Полная цепочка обработки документа контролируется на уровне
систем организации документооборота отдела или на уровне специального делопроизводства (см. рис. 6.5).
251
6.12. МЕТОДЫ СВЯЗЕЙ С ВНЕШНИМ МИРОМ
Выше была описана работа централизованной канцелярии организации. В принципе, в крупной организации с большим документопотоком работа канцелярии
может быть построена по децентрализованному принципу. При этом каждое подразделение предприятия получает долю корреспонденции, относящуюся к ней.
При этом учет входящей корреспонденции осуществляется децентрализовано. Номера входящей корреспонденции создаются или в едином нумераторе (кто первый
получил номер, тот и хорош), или в номер входящего документа включается номер
подразделения, получившего документ, а нумераторы в каждом подразделении
ведутся независимо. Исходящая корреспонденция обычно всегда проходит через
одно место (по крайней мере, пока не известны предприятия с другой схемой обработки исходящей корреспонденции).
Организация децентрализованного приема входящих документов достаточно
распространена и во всем мире. Достаточно привести пример газеты Times.
При реорганизации отдела обработки писем граждан в конце 80-х гг. (тоже канцелярия, но специализированная) значительная часть работы по сортировке корреспонденции была передана Британскому почтовому ведомству. Для этого газета
стала принимать корреспонденцию в несколько абонентских почтовых ящиков (до
этого она имела один адрес для всей корреспонденции). После двух лет эксплуатации выяснилось, что число ошибок в адресах (отправлено не в тот абонентский
ящик) составляет меньше 2 %. Данная реорганизация позволила сократить количество сотрудников отдела обработки входящей корреспонденции в 2 раза (или
в 6 в сравнении с конкурирующим вариантом). Кстати, это яркий пример того, что
процесс анализа документопотоков может принести значительный результат
не только если он заканчивается полной автоматизацией предприятия.
В работе канцелярии пока темным местом остается работа с письмами граждан. В большинстве случаев это относится к общему делопроизводству. Исключение составляют организации, для которых работа с письмами составляет основную
производственную деятельность (телерадиокомпании, газеты, журналы, информационные агентства и другие средства массовой информации).
При обработке писем граждан применяются несколько другие классификаторы. Важна развернутая статистика по атрибутам писем. Это основывается на опыте
разработки Автоматизированной системы обработки корреспонденции (АСОК)
Гостелерадио России (тогда еще СССР). Кстати, эта система до сих пор находится
в эксплуатации, хотя и выполняет несколько иные задачи, чем ранее. В крупных
государственных организациях тоже существует специальный учет писем граждан
и строгий контроль за их выполнением (примеры – Государственная дума России,
Национальный банк Украины). Таким образом, блок обработки писем граждан еще
нуждается в исследовании и описании.
6.13. ОЦЕНКИ ОБЪЕМОВ ДОКУМЕНТООБОРОТА
В данном подразделе приведены некоторые оценки объемов корреспонденции
для различных организаций. Так, например, через канцелярию центрального офиса
252
Национального банка Украины за год проходит: 16 тыс. единиц входящих документов (помимо этого еще порядка 8 тыс. документов поступают децентрализовано непосредственно в подразделения банка), 25 тыс. писем граждан, 24 тыс. единиц исходящих документов. При этом список данных документов непосредственно
в канцелярии хранится в течение 3 лет для 90 % документов, а оставшиеся 10 %
в течение 5 лет. Тексты документов хранятся в канцелярии (в архивном отделе)
до конца текущего года, далее они передаются в архив на долговременное хранение. Передача документов на архивное хранение может осуществляться и более
мелкими порциями, несколько раз в год.
Документооборот Государственной думы имеет несколько больший объем –
90–120 тыс. документов в год. Документооборот Дома Правительства Российской
федерации составляет 90–110 тыс. документов в год (эти цифры приведены безучета писем граждан). Характерные сроки хранения перечня документов для этих
организаций – 5 лет для думы и 1 год для аппарата Правительства. Далее все
документы передаются в архив. К сожалению, подразделение по типам документов
в этих организациях неизвестно. Можно считать, что входящие и исходящие представлены примерно в равных пропорциях.
Рассчитаем необходимые объемы базы данных для хранения таких объемов
документов.
Карточка документа занимает примерно 2 кб на диске (цифра, характерная
для сложной карточки документа в DOCS Open). Еще 1 кб на карточку занимает ее
индекс. Таким образом, под один документ на диске требуется 3 кб дискового пространства для данных. Учитывая то, что крупная организация имеет поток порядка
50–100 тыс. документов в год и карточка документа храниться в течении 3 лет,
то для хранения 150–300 тыс. документов потребуется примерно от 0,5 до 1,0 Мб
на диске.
6.14. ОТЧЕТНОСТЬ КАНЦЕЛЯРИИ О ПРОДЕЛАННОЙ РАБОТЕ
Основным результатом работы канцелярии являются отчеты о потоке документов на предприятии, которые она предоставляет руководству предприятия. Отчеты условно можно разделить на две большие группы:
• Оперативные. Они выводятся или ежедневно, или еженедельно. Основное
их назначение – получить объективную картину информации для оперативного
управления.
• Аналитические. Они служат для анализа общей картины документооборота
на предприятии. Типичные периоды вывода отчетов данной группы – месяц, квартал, полугодие, год.
Рассмотрим основные отчеты, т. е. такие отчеты, которые присутствуют практически в каждой канцелярии.
Оперативные отчеты. Назначение данного вида отчетов – получение информации для оперативного управления предприятием. Они готовятся на различную глубину – от одного дня и до недели. Основное их содержание – список работ,
которые должны быть завершены в ближайшее время. Получатели отчетов –
253
ответственные исполнители и руководство предприятия. Отчеты бывают сводными и индивидуальными.
Индивидуальные отчеты представляют собой сводку работ, находящихся
в компетенции того или иного должностного лица.
Сводный отчет – это список работ, находящихся в стадии завершения на заданный период времени (возможно, разделенный на отдельные подразделы по различным признакам). Сводные отчеты поступают к руководству предприятия или
к руководству канцелярии для общего контроля процессом делопроизводства. Индивидуальные отчеты поступают непосредственно к исполнителям или контролирующим лицам.
При рассмотрении отчетов не производится их группировка (т.е. на самом деле отчетов может быть и меньше, если использовать специализированные фильтры). У каждого оперативного отчета должен быть фильтр, задающий интервал
времени, в который происходит окончание работ. Данные этого фильтра помещаются в заголовок отчета. Типичными примерами таких отчетов могут являться:
• Завершающиеся работы по исполнителям.
• Сводный отчет по подразделениям организации.
• Сводный отчет по контрагентам и т.д.
Аналитические отчеты. Аналитические отчеты выдают информацию о проделанной работе. Хотя существуют достаточно стандартные формы отчетов, каждая организация может захотеть иметь собственные формы отчетов (в том числе
и матричные). Данные отчеты служат для планирования работы организации
в дальнейшем, для анализа номенклатуры предприятия списка контрагентов и т. д.
Аналитические отчеты могут выдаваться по отдельным структурным подразделениям организации. Отчеты должны давать картину работы предприятия за определенный период времени. Следовательно, в фильтр отчета нужно ввести параметр –
время анализа.
В нем можно задавать или произвольный интервал времени, или фиксированный и понятный:
• За месяц (указывается месяц и год, по умолчанию текущий).
• За квартал (по умолчанию за текущий квартал).
• За год (по умолчанию за текущий год).
Аналитические отчеты выдаются сравнительно редко. Часто их оформляют
в виде отдельного издания и распространяют по всей организации. В связи с этим
к ним предъявляются достаточно высокие требования по качеству оформления.
В общем случае они должны включать логотипы предприятия, гербы и прочую
графическую символику.
Примеры таких отчетов:
• Исполненные документы по исполнителям.
• Исполненные документы по контрагентам.
• Исполненные документы по номенклатуре.
• Взаимосвязи системы автоматизации документооборота канцелярии.
Канцелярия крупного предприятия является центром документооборота, но
на ней документооборот не заканчивается. Она тесно связана с документооборотом
254
подразделений предприятия, с системами поддержки принятия решений и с архивом предприятия. В общем случае можно рассматривать систему автоматизации
документооборота организации как центральную, осуществляющую координацию
остальных подсистем документооборота, своеобразного ядра системы автоматизации производственной деятельности предприятия (рис. 6.11).
Схема организации системы управления предприятия
(в разрезе документооборота)
Рис. 6.11. Взаимосвязи канцелярии и остальных подразделений организации
На одном уровне с канцелярией стоит архив предприятия, который служит
для накопления документов, долговременного хранения и их поиска.
6.15. КАНЦЕЛЯРИЯ И АРХИВ ПРЕДПРИЯТИЯ
Все документы, проходящие через канцелярию, попадают в архив предприятия. Рассмотрим организацию документов в архиве предприятия.
Все документы подразделяются на дела. Одно дело объединяет все документы
за один год работы предприятия по тому или иному пункту номенклатуры дел организации. Объем единицы хранения в архиве не может превосходить 200 страниц.
В связи с этим для больших дел вводятся несколько томов. Таким образом, подразделение документов в архиве происходит по делам, а затем по томам. Поиск
255
информации осуществляется как по атрибутам дел и томов, так и по атрибутам
документов.
Дела в архив передаются из канцелярии или отдельно (по томам), или целиком по окончании года. В любом случае дело закрывается в конце года. При этом
проверяется полный перечень документов в деле, их разбивка по томам. После
этого готовится опись дел, в которой указывается список дел (по их наименованием), количество томов в деле, количество страниц в каждом томе. После составления описи дел за конкретный год они поступают на хранение.
Сроки хранения для разных позиций номенклатуры различны. Типовые сроки
хранения документов в крупной организации: 1, 3 года и 5, 10, 30, 50 лет. После
истечения срока хранения дела оно из архива предприятия передается на хранение
в государственный архив (для государственных организаций). Для частных компаний после истечения срока хранения дела уничтожаются. И тот и другой процесс
оформляется соответствующими актами. Дела в архив или на уничтожение поступают как единое целое, т. е. в отличие от процесса формирования архивных дел
запускается соответствующая операция для всех томов дела.
6.16. КАНЦЕЛЯРИЯ И ДОКУМЕНТООБОРОТ УРОВНЯ ОТДЕЛА
Документооборот на предприятии не заканчивается только канцелярией. Мало того, он только начинается в канцелярии, а основная часть документооборота
проходит через подразделения организации. В принципе, канцелярию за редким
исключением не волнует документооборот в отделах. Только в некоторых случаях,
когда канцелярии предъявляют претензии за вовремя неисполненные документы,
ее серьезно волнует положение дел в подразделениях.
На уровне подразделений документооборот должен позволять вести внутренний
документооборот и передавать дела в канцелярию и, возможно, в другие подразделения предприятия. Документооборот уровня отдела отличается от документооборота уровня подразделения тем, что дела свободно ходят в рамках подразделения.
Переходы дел между отделами внутри одного подразделения не регистрируются,
но выход дела за рамки отдела должен отслеживаться и регистрироваться.
6.17. КАНЦЕЛЯРИЯ И СПЕЦИАЛИЗИРОВАННОЕ ДЕЛОПРОИЗВОДСТВО
Специализированным делопроизводством можно считать любую специализированную систему, работающую с структурированными данными, такую как бухгалтерию, торговую систему и т. д. Иногда предприятию удобно рассматривать
часть неструктурированного документооборота, как специализированную систему
делопроизводства. Некоторые специализированные системы делопроизводства
могут работать с собственными архивными системами (например – бухгалтерия,
торговые или банковские системы и т. д.), в которых документы хранятся в структурированном сложноорганизованном виде.
Чаще всего такие системы характеризуются следующими параметрами:
256
• Они связаны с основной производственной деятельностью организации.
• На них существуют жесткие маршруты прохождения документов (можно
и нужно применять системы жесткой маршрутизации).
• Они работают с структурированными документами.
• Документы подвергаются сложной и специфической обработке или имеют
развитую семантику, которую нужно программно проверять и поддерживать (контракт–счет–накладная).
С маршрутов обработки документов возможен выход в общую систему делопроизводства, например, для обсуждения проекта документа или для получения
справок из других отделов или подразделений предприятия. В общем делопроизводстве основная схема работы с заданиями и документами – это свободная маршрутизация. Она отвечает за сбор и распределение информации, за связи с внешними организациями (вне основного производственного процесса). Во все специализированные системы делопроизводства от нее есть отростки для обмена
информацией.
6.18. МЕТОДЫ И СРЕДСТВА АВТОМАТИЗАЦИИ
УЧРЕЖДЕНЧЕСКОЙ ДЕЯТЕЛЬНОСТИ
Долгое время автоматизация учреждений в России осуществлялась в виде
различного рода подсистем АСУ, основанных на базах данных (кадры, канцелярия,
бухгалтерия, зарплата, контроль исполнения и др.) Не умаляя значимости этих
подсистем, заметим, что они охватывали лишь до 15–20 % общего объема информации, циркулирующей в учреждении.
Нужды по электронной обработке документов удовлетворялись применением
функциональных пакетов (редакторов текста и электронных таблиц) и интегрированных пакетов программ Microsoft Office, Perfect Office, Lotus Smart Suite. Эти
средства оказались недостаточными для управления огромными потоками бумажных и электронных документов, циркулирующих как внутри одного предприятия,
так и между ними. В целом, такой подход отличался отсутствием комплексности
в автоматизации делопроизводства и управления документооборотом.
В настоящее время развитие информационных технологий привело к появлению методов и средств, обеспечивающих интегрированные решения по автоматизации офиса, позволяющие автоматизировать ручные операции и поиск документов, автоматически передавать и отслеживать перемещение документов и контролировать выполнение поручений, связанных с документами.
6.19. МЕТОДЫ АВТОМАТИЗАЦИИ УЧРЕЖДЕНИЙ
Рассмотрим основные методы автоматизации учрежденческой деятельности.
Современные организации представляют собой совокупность подразделений, филиалов, отделов и офисов, обменивающихся между собой информацией и выполняющих отдельные части общей работы. Основными фазами жизни неструктурированной информации в офисе являются:
257
• ввод информации в систему,
• хранение, навигация, поиск и фильтрация документов,
• коллективная работа с документами,
• вывод информации из системы.
Существуют различные способы ввода информации в систему. Это прежде
всего сканирование документов и сохранение их в виде графических образов.
В системах первого поколения графические образы введенных документов идентифицируются с помощью ключевых слов для последующего поиска необходимой
информации (например: система SoftSolutions). Позднее стала применяться
технология оптического распознавания символов OCR (Optical Character
Recognition). После сканирования и ввода документа в систему его графический
образ «переводится» в текст, затем следует исправление ошибок распознавания.
При массовом ручном вводе однотипных документов используются электронные формы, которые обеспечивают структуризацию документа путем выделения
частей текста и добавления полей (атрибутов), что позволяет упростить заполнение документов и выполнить необходимые вычисления. Информация в офис может поступать и путем импорта файлов с магнитных носителей или по телекоммуникациям (факсы, сообщения электронной почты и т. п.).
Ввод информации сопровождается классификацией документов путем задания атрибутов и ключевых слов, аннотированием их содержания. Для ускорения
последующего контекстного поиска производится полнотекстовое индексирование
документов.
Важное значение для организации эффективного управления неструктурированными документами имеют методы хранения информации, навигации, поиска
и фильтрации документов.
Документы могут храниться просто в файловой системе, и при этом система
каталогов служит средством группирования и навигации в хранилище документов.
В современных ОС типа Windows 95 есть возможность задания длинных имен каталогов и файлов в качестве названий папок и документов, а также имеются соответствующие средства поиска файлов по их параметрам.
Ряд систем, основанных на электронной почте, хранят документы в почтовых
ящиках в виде почтовых сообщений с присоединенными файлами. Навигация
в хранилище упрощается с помощью вложенных папок личного и коллективного
пользования. Однако в таких системах поиск и фильтрация ограничены лишь отбором и сортировкой документов по атрибутам и тексту почтового сообщения.
Специфический метод хранения реализован в пакете Lotus Notes в виде так
называемой базы документов. База документов может хранить как однотипную,
так и разнотипную информацию в виде одного файла. Документы допускают внутреннюю структуризацию на основе формуляров путем выделения и добавления
полей в документе. Навигацию в базе документов упрощает наличие страниц баз
документов и категорий документов. Почтовые сообщения также хранятся в виде
базы документов, файлы произвольного вида допускается присоединять к текстовым документам.
258
Многие современные системы электронных документов используют в дополнение к файловой системе так называемые библиотеки документов, содержащие
в БД карточки документов с атрибутами и ключевыми словами. Для логической
группировки документов применяются папки.
Поиск и фильтрация документов производится по запросам на основе контекстного поиска: по атрибутам, по ключевым словам и по полному содержанию текста на основе индекса. При использовании механизма четкого поиска (например,
DOCS OPEN) в запросе не должно быть орфографических ошибок, а в тексте документа – ошибок распознавания.
Недавно на основе нейронных сетей и искусственного интеллекта реализована
технология нечеткого поиска по полному содержанию документа (например, технология адаптивного распознавания образов APRP в пакете Excalibur EFS). Нечеткий поиск не требует полного соответствия искомых фраз с содержимым документов, кроме того, исключает потребность в исправлении ошибок после распознавания текста. Система поиска всегда выдает пользователю ответ, наилучшим
образом согласованный с терминами или фразами запроса.
Фирмы-производители реляционных СУБД (в частности, ORACLE) проповедуют другие схемы хранения – текстовые и универсальные БД. Тексты документов
хранятся в символьных полях переменной длины, расширенные средства SQLпоиска позволяют формировать смешанные запросы для поиска по атрибутам
и контекстного поиска, а дополнительные функции обеспечивают обработку текста. Для хранения произвольной информации, в том числе мультимедиа, можно
использовать поля бинарных объектов большой длины BLOB и/или гипертекст.
СУБД, расширенные для поиска и обработки такой информации, образуют универсальные сервера БД. Другой способ хранения документов произвольного содержания реализуют объектно-ориентированные БД (например, Informix Illustra).
Феномен распределенного гипертекста составляет основу широко внедряемой
web-технологии. Хранилище информации представляет собой совокупность гипертекстовых страниц, распределенных по узлам сети Internet или корпоративной сети
(Intranet). Каждая страница размещается в отдельном файле и представляет собой
текст, размеченный с помощью языка HTML. Структуризация документа осуществляется путем форматирования, выделения полей, создания форм для диалогового
заполнения документа и организацией внутренних гипертекстовых ссылок. Допускается создание гипермедиа включением любой мультимедиаинформации (растровая графика, аудио, видео). Навигация по хранилищу гипертекста осуществляется
с помощью внешних гипертекстовых ссылок URL на документы, расположенные
на различных узлах сети (web-серверах). Кроме того, для определения местонахождения документов служит контекстный поиск. Для ускорения поиска информации в «паутине» применяются специальные программы-роботы, сканирующие
web-сервера и строящие некое подобие индекса. Использование гипертекста позволяет создать информационную инфраструктуру территориально распределенного учреждения и упростить диалоговый интерфейс пользователя, что наиболее
важно при разработке информационных приложений для руководителей.
259
Организация и автоматизация в офисе коллективной работы с документами
строятся на технологиях groupware и workflow.
Технологии groupware ориентированы на небольшие рабочие группы, характеризуются поддержкой выполнения одной коллективной задачи и отсутствием
структуризации в организации работ. Поддержка ограничивается обеспечением
коллективного доступа к информации с помощью различных методов доступа:
• сетевой доступ к файлам и базе данных,
• локальная и глобальная электронная почта (включая конференции и дискуссии),
• терминальный доступ, пересылка файлов и электронная доска объявлений,
• просмотр и интерпретация гипертекста (гипермедиа).
Нужно отметить, что web-технологии помимо гипертекстового протокола
HTTP включают в себя ряд других методов доступа.
При коллективной работе важно наличие блокировок для разрешения конфликтов при совместном использовании ресурсов, санкционирование доступа по
идентификаторам и паролям, защита информации с помощью прав доступа. Дополнительный уровень безопасности обеспечивается методами и средствами шифрации и электронной подписи.
Технологии класса workflow служат для автоматизации документооборота
в средних и крупных офисах и для них характерны:
• поддержка многопользовательской работы с несколькими задачами одновременно;
• четкая структуризация выполнения работ по ролям и документам с контролем исполнения.
Деловой процесс формализуется как совокупность состояний и переходов, необходимых для описания взаимодействия, как минимум, двух субъектов (в частном случае сотрудников предприятия) для достижения выполнения заранее заданного условия. Частным случаем такого взаимодействия является простая пересылка документа из точки в точку.
Одной из реализаций технологии workflow является так называемая «система
графов», где каждый шаг представляет собой вектор и отражает движение задания,
связанного с документом, или просто передвижения документа от одного субъекта
к другому. При этом на человека, отвечающего за правильность функционирования схемы, ложится ответственность учета всевозможных непредвиденных (или
отказных) ситуаций, которые могут возникнуть на пути движения документа.
Другая реализация основывается на понятии «цикл» («loop») или «стол».
В этом случае подразумевается, что наименьшим элементом в схеме взаимодействия является цикл, учитывающий всю гамму взаимодействия между двумя произвольными субъектами. При этом система сама отслеживает замкнутость процесса
и в случае ошибки указывает место некорректности с определением ее причины,
после чего прекращается генерация нового процесса.
Регламентация взаимоотношений субъектов документооборота дополняется
заданием безусловной и условной маршрутизации документов (по электронной
почте) и времен обработки документа для контроля и учета исполнения.
260
Обработка информации базируется на методах и средствах офисной автоматизации:
• обработка текста,
• электронные таблицы,
• деловая и презентационная графика,
• планирование работ и совещаний,
• генерация отчетов из базы данных,
• мультимедиа.
Для комплексирования разных видов информации и интеграции пакетов программ используются несколько методов, среди которых центральное место занимают методы OLE для связывания и встраивания объектов.
Вывод информации осуществляют путем печати документов, публикации их
на web-серверах, в общих почтовых папках и электронных досках объявлений или
рассылки по телекоммуникациям.
6.20. СРЕДСТВА АВТОМАТИЗАЦИИ УЧРЕЖДЕНИЙ
И КОЛЛЕКТИВНОЙ РАБОТЫ В СЕТЯХ
Информационно-программные средства автоматизации учреждений делятся
на следующие категории:
• функциональные и интегрированные пакеты офисной автоматизации,
• системы для организации групповой работы,
• системы управления электронными документами,
• средства управления документооборотом.
В качестве средств офисной автоматизации и коллективной работы в сети
применяют следующие пакеты.
Пакет Microsoft Office for Windows 95. Microsoft Office for Windows 95 представляет собой набор прикладных программ для автоматизации работы современного офиса, которые объединены в один пакет и работают как единое целое.
Microsoft Office for Windows 95 поставляется в двух различных вариантах, что
позволяет удовлетворить потребности всех пользователей. Microsoft Office
Standard имеет в своем составе электронную таблицу Microsoft Excel, текстовый
процессор Microsoft Word, систему подготовки презентаций Microsoft PowerPoint
и планировщик Microsoft Schedule+. Microsoft Office Professional помимо вышеперечисленных приложений включает в себя также СУБД Microsoft Access.
Microsoft Office for Windows 95 использует все преимущества Windows 95:
поддерживаются длинные имена файлов, «горячие клавиши» и многозадачность.
Пользователь получает доступ к почтовой станции Microsoft Exchange для обмена
факсами и электронными письмами.
Microsoft Office for Windows 95 – это не только набор приложений, но и платформа для разработки. Разработчики могут использовать Microsoft Office в качестве основы для создания собственных приложений, предназначенных для удовлетворения конкретных нужд заказчика.
261
Microsoft Office for Windows 95 содержит мощные инструментальные средства для разработки. Система Lotus Notes представляет собой платформу типа клиент–сервер, служащую для разработки и размещения прикладных программ группового обеспечения.
Благодаря тому, что система Lotus Notes объединяет важные технологии, необходимые для подготовки этих приложений, она предлагает разработчикам наиболее производительную платформу, ориентированную на совместное использование информации.
Система Lotus Notes позволяет пользователям получать, отслеживать, совместно использовать и создавать информацию, предназначенную для документов.
Эта информация может поступать в различных форматах, таких как тексты, изображения, видео и звук, и от различных источников, таких как компьютерные прикладные системы, оперативные системы или системы деловых линий (Line of
Business Systems), сканеры или факс-аппараты. Пользователям система Lotus Notes
обеспечивает доступ к сети через любой применяемый ими графический пользовательский интерфейс (Windows, Mac, OS/2, Unix).
Основными характеристиками системы Lotus Notes являются:
1. Единый, постоянный пользовательский интерфейс для обращения ко всем
другим пользователям, сетевым ресурсам и информации.
2. Гибкость при обработке сложных документов, содержащих данные различного рода от таких источников, как компьютерные приложения, новостные каналы
(newsfeeds), сканированные изображения и структурированные реляционные системы.
3. Среда быстрой разработки прикладных программ для рабочих групп.
4. Развитая система защиты доступа к информации на всех уровнях, вплоть
до уровня отдельного документа.
5. Применение тиражирования для предоставления всем пользователям доступа к свежей информации, располагающейся в любом подразделении предприятия, в его филиалах, у удаленных пользователей, а также у заказчиков и поставщиков.
6. Открытость, заключающаяся в поддержке множества сетевых и компьютерных операционных систем, компьютерных приложений, внешних источников
данных, систем передачи сообщений и прикладных программных интерфейсов API.
7. Масштабируемость – возможность поддерживать организации любого размера, от рабочей группы из двух пользователей до корпоративной сети с десятками
тысяч пользователей.
8. Полная интеграция набора разнообразных элементов клиентских и серверных программных модулей (среда пользователя, распределенная обработка документов, передача сообщений, защита и среда разработки), необходимая для создания технологии бизнес-процесса заказчика на множестве платформ.
Рабочее пространство пользователя (Workspace) системы Lotus Notes представляет собой графический пользовательский интерфейс, который знаком пользователям систем Windows, Mac System7, OS/2 или Unix.
Рабочее пространство системы Lotus Notes состоит из шести фиксированных
экранных окон, в которых размещены пиктограммы, представляющие документные
262
базы данных системы Notes. Пользователь может располагать окна на экране
по своему усмотрению.
База документов Notes представляет собой средство хранения объектов,
при помощи которого пользователи могут вызывать, отслеживать, хранить и преобразовывать информацию в своей сети. База документов может совместно эксплуатироваться пользователями, присоединенными к одной и той же сети.
Сложные документы, составляющие базу данных, создаются и обновляются
при помощи бланков Notes Forms и редактора WYSIWYG, который позволяет
пользователю вводить и редактировать текст или применять неделимые объекты
системы Notes.
Система Lotus Notes использует средства OLE и другие программные мосты
для интеграции с различными прикладными программами.
6.21. СРЕДСТВА УПРАВЛЕНИЯ ЭЛЕКТРОННЫМИ ДОКУМЕНТАМИ
В любом учреждении рано или поздно становится актуальным вопрос наведения порядка в информационных потоках. Определяющим фактором является время, требуемое для поиска необходимого документа или для подборки материалов.
Стержнем любой системы управления электронными документами является
архив, где документы находятся в процессе работы над ними и где они остаются
до тех пор, пока содержащаяся в них информация представляет интерес.
Под электронным архивом понимается совокупность аппаратно-программных
средств и технологий для создания хранилища электронных документов и обеспечения досту