Н.А.Пиликов, Р.М.Юсупов

Этот адрес электронной почты защищен от спам-ботов. У вас должен быть включен JavaScript для просмотра. №2, 1998

Все мы являемся свидетелями того, что произошло с мощностями и пользовательскими возможностями персональных компьютеров (ПК) на платформе Intel/Windows. От простого однопрограммного домашнего или офисного прибора всего за несколько лет ПК совершил гигантский революционный скачок в сторону реальной многозадачной, многопользовательской высокопроизводительной рабочей среды для самых разнообразных приложений в бизнесе и промышленности.

Фирма Microsoft, поставляющая базовые программные решения для ПК, совершила "техническое чудо", обеспечив комплексные программные решения за цену, доступную практически всем. Впервые в истории человечества обладание серьезными компьютерными ресурсами стало явлением массовым, а работа на компьютере перестала требовать от пользователя какой-то серьезной технической квалификации. Активно решать свои проблемы на ПК теперь может любой школьник, бухгалтер, юрист, технолог и т.д. Системные решения Microsoft сформировали простые пользовательские стандарты в сложном взаимодействии человека и компьютерной среды, благодаря чему и пошел обвальный процесс массового рапространения ПК. Когда-то нечто аналогичное произошло с автомобилем, однако, срок эволюции с момента, когда автомобилем могли пользоваться только талантливые или богатые одиночки до массового использования исчисляется многими десятилетиями.

Как же это удивительное по проявленному темпу явление сказалось на современном быстро растущем рынке MCAD/CAM систем, то есть систем автоматизированного проектирования и подготовки производства механических конструкций? Чтобы ответить на этот важный для любого руководителя машиностроительного предприятия вопрос необходимо вернуться всего лишь на несколько лет назад, а именно, к началу 90-х годов.

Совершенно очевидно что в конце 80-х, начале 90-х годов, мир MCAD (Mechanical CAD) систем четко делился на 2 существенных класса:

• Класс "легких" систем (по-английски low-end), базирующихся на ПК под системой MS DOS - AutoCAD, CADKEY, Personal Designer
• Класс "тяжелых" систем (по-английски high-end), базирующихся на рабочих станциях под операционной системой UNIX - CATIA, Pro/E, UNIGRAPHICS, CADDS4X, EUCLID

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

Рис.1. Традиционное распределение функций между легкими и тяжелыми системами

Сетевые решения, увязывающие работающие группы проектировщиков, могли строиться только на платформе UNIX, так как только многозадачные и многопользовательские системы могли поддерживать в то время корректный распределенный доступ к общим проектным данным и обеспечивать их защиту. В силу этого, организация одновременной работы в группе (допустим, в КБ, проектирующем самолет или турбину) требовала укомплектования рабочих мест только базе тяжелых систем с привлечением сетевых конфигураций, совместимых с этими системами. В результате, любое мероприятие по групповой автоматизации неизбежно требовало единиц или десятков миллионов долларов. С этой ситуацией столкнулись практически все предприятия, стоящие перед необходимостью автоматизации проектирования.

Технический прорыв, совершенный за счет новейших достижений в информационных технологиях, начался с появлением операционных систем Windows 95/NT, которые реально сформировали на обычном ПК многозадачную и многопользовательскую среду. Во первых, это привело к существенному удешевлению и возрастанию мощностей систем обоих типов. Но самое главное, состоит в том, что это привело к появлению совершенно нового класса MCAD систем: системам среднего типа, получившие по английски специальное название Mid-Range системы: SolidWorks, AMD, SolidEdge, Microstation, Eureka, Anvil Express, и т.д. Их главное отличие в том, что они специально проектировались для новой платформы Windows 95/NT и в силу этого наиболее эффективно используют новую рабочую среду.

Рис.2. Распределение функций с учетом систем типа Mid-Range.

Таким образом, системы легкого класса в максимальной степени сокращают свою пользовательскую нишу и уходят в сектор автономного черчения и 2D построений, никак не связанных с объемным проектированием. Системы автономного черчения не должны предлагаться там, где так или иначе требуется объемное построение.

Системы тяжелого класса должны уступить нишу объемного проектирования в самом массовом секторе объемного проектирования простых и средних деталей и конструкций системам среднего класса. Для них остается:

• проектирование деталей самого сложного типа, содержащих поверхности, отвечающие требованиям обтекаемости или каким-то специфичным математическим критериям
• проектирование массивных сборок, требующих тщательной компоновки и содержащих элементы инфраструктуры (кабельные жгуты, трубопроводы)

По оценкам западных экспертов системы среднего класса могут поглотить до 80% типичных машиностроительных задач. Закономерен вопрос, так ли важно создавать средний класс систем, усложняя и без того непростую ситуацию с выбором MCAD-систем? Ответ на этот вопрос мог бы быть опять сделан по аналогии с автомобильной промышленностью. Ни у кого нет сомнения в том, что ГАЗ не смог бы просуществовать, не выпустив автомобиль среднего класса на базе Газели. Талантливое решение было как раз связано с правильным видением роли "среднего класса" машин для клиентов, которые уже давно работают в условиях жесткой конкуренции, где важен каждый сэкономленный рубль. Совершенно аналогичная ситуация создалась на рынке MCAD-систем, где соотношение продуктивности к цене у новейших систем среднего класса превосходит все ожидания.

Совершенно очевидно, что намечая реконструкцию предприятия в целом нельзя не учитывать вновь сложившиеся обстоятельства. Технология от Microsoft все в большей степени влияет на распределение глобальных компьютерных ресурсов в мире, и было бы ошибкой делать ставку только на технологию начала 90-х годов, когда практически все профессионально грамотные решения исходили только от систем уровня UNIX. Технология систем UNIX также будет развиваться, но совершенно очевидно, что темп развития и качество решений по системной поддержке компьютерных ресурсов выше у Microsoft. Сравнительный анализ этих двух технологий представляет из себя серьезную задачу, которой посвящают аналитические статьи многие эксперты. Наиболее интересен февральский выпуск журнала CADENCE Channel со статьей американского специалиста Мишеля Пиллерса "MCAD Mid-Range Modelers: State of the Art", что можно перевести как "MCAD системы среднего класса: на грани искусства".

Именно в этой статье уделяется внимание не только изначальным ценовым факторам при сравнении различных систем, но и соотношению длительности обучения к проценту "применяемости" (usability) приобретенных при обучении навыков.

Необходимо четко давать себе отчет в том, что тяжелые системы в операционной среде UNIX потребуют гораздо больше усилий и времени для обучения только из-за того, что UNIX - чисто англоязычная рабочая среда, имеющая более низкое тиражирование, чем системы от Microsoft. UNIX изначально рассчитана на научные приложения, поэтому существенно уступает Microsoft Windows по комфортабельности работы, следовательно по доступности. Знание Microsoft Windows, во многом за счет руссифицированной версии становится массовым явлением, стандартом любого компьютерного образования. Это значит, что системы, специально спроектированные для Microsoft Windows, будут осваиваться быстрее. Примечательно, что в этой важнейшей области традиционные примеры ведущих предприятий стран Запада не являются объектом для подражания. То, что в компании, например, Pratt & Whitney системой UNIGRAPHICS охвачены все проектирующие специалисты (более 2500 рабочих мест), в существенной степени обусловлено тем, что весь этот контингент говорит и работает на английском как на родном, и решение о тотальной автоматизации принималось компанией в период, когда систем среднего уровня еще не было. Реально рассматривая возможности специалистов на наших предприятиях, эффект массовой автоматизации пока возможен только на базе адаптированной на нашего клиента версии Microsoft Windows. Система UNIX, в свою очередь, может быть эффективно использована только на самых сложных участках работы, куда привлекаются наиболее талантливые исполнители, для которых языковые и интеллектуальные сложности освоения не являются проблемой.

По каким же критериям нужно оценивать системы? Результаты приводятся в таблице 1.

Таблица 1.

Таблица 2.

*- Включая модуль черчения и обмена данными

**-Включая модуль черчения и моделирования поверхностей

Рис.3 Соотношение стоимости и эффективности САПР.

Кроме перечисленных трудностей выбора типа системы между тяжелым и средним вариантом, руководителю придется столкнуться с фактором "уникальности" специалистов. Вопрос такого рода в рамках корпорации может оказаться исключительно важным. Исторически существуют много примеров, когда специалисты, освоив сложный программный инструмент, использовали свои уникальные знания для лоббирования высокой заработной платы или просто терроризировали руководство возможностью ухода из компании. В свое время в 70-х годах, когда появился язык программирования КОБОЛ, который по уровню учебной документации мог быть освоен только самыми способными специалистами, фирма IBM столкнулась с проблемой опасной зависимости от своих же разработчиков на КОБОЛе. Проблемы потери этих людей были настолько пагубны для компании, что IBM решила инвестировать многие миллионы долларов в глобальную учебную программу по программированию на КОБОЛе. КОБОЛ стал преподаваться практически в каждом университете, в результате всего лишь за год рынок просто наводнился программистами на КОБОЛе, и фактор "уникальности" в этой сфере быстро исчез. Но далеко немногие предприятия располагают такими финансовыми возможностями и таким влиянием как IBM.

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

В данном случае, сравнивая стоимость учебной инфраструктуры для типичных представителей тяжелой и средней систем, можно сразу отметить, что эти затраты имеют следующие компоненты:

Таблица 3.

Очевидно, что буквально по всем позициям системы среднего уровня существенно выигрывают системы среднего уровня

Вопрос выбора решений для рабочих мест должен органично сочетаться с выбором системы по управлению проектными данными - Product Data Management (PDM). Системы класса PDM необходимы для обеспечения согласованной и корректной работы больших групп проектирующих специалистов, иными словами интеграции всего комплекса.

Традиционное классическое решение для предприятия в целом (корпоративный уровень) до сих пор состояло в том, что системы PDM разного класса, как правило привязаны к какому-то одному типу системы, иными словами существующие системы такого типа являются гомогенными. Например, UNIGRAPHICS предполагает для интеграции только систему IMAN, CADDS5 - только систему Optegra, CATIA - только систему CDM, Pro/E - Pro/PDM. Наличие таких жестко связанных пар вызвано не только тем, что разные системы имеют разные форматы данных. Хотя, есть небольшие исключения, например, Optegra "понимает" формат данных систем CATIA, Pro/E, но тем не менее основной набор функций реализуется только на "родной" системе CADDS5. Основной смысл таких парных построений состоит в том, что фирма-поставщик, предложив клиенту корпоративное решение по PDM, "заставляет" его таким образом и дальше покупать только свою систему. Понятно, что корпоративная система может быть только одна, следовательно, если клиент ее выбрал и на ней укрепился, у него уже не будет выбора на какую-то иную MCAD-систему.

Клиенту надо быть гораздо более осторожным в выборе PDM как корпоративного решения, чем при выборе самих MCAD-систем, чтобы не попасть в маркетинговую "удавку" под предлогом глобальной и все сокрушающей интеграции. Гомогенные системы PDM являются исключительно удобным рычагом для дальнейшего вытягивания денег с "увязшего" клиента. Клиент нужно всегда требовать, чтобы система PDM была гетерогенна, допускала бы интеграцию с другими системами по специально разработанным интерфейсам. Именно, по требованиям таких клиентов как Rover фирма Computervision вынуждена была доработать стыковку системы Optegra с системами AutoCAD и CATIA.

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

1. Системы легкого класса сужают свою нишу до уровня автономного персонального использования, поэтому в структуре корпоративных решений могут занимать лишь небольшие участки на уровне отдельных исполнителей (как, например, калькуляторы).
2. Решение по конфигурированию предприятия в целом на базе какой-то одной системы на платформе UNIX является решением устаревшей архитектуры начала 90-х годов. Опыт западных предприятий, построенных полностью на базе систем UNIGRAPHICS, CATIA, CADDS, Pro/E и т.д. - не является примером для подражания в наше время. Новейшие технологии Microsoft, по которым начинает работать весь мир, невозможно обойти или проигнорировать.
3. Конфигурирование должно происходить по принципу - тяжелые дорогостоящие системы должны использоваться только там, где невозможно или нецелесообразно использовать средние системы.
4. Инфраструктура обучения должна закладываться в самом начале проекта, иначе предприятие понесет существенно большие расходы.
5. Система по управлению проектными данными (PDM) должна быть гетерогенной, понимать все активно используемые форматы данных, если она понимает только какой-то узкий класс MCAD-систем, она просто не отвечает своему назначению как интегрирующее решение.
6. Руководству нужно сразу избавиться от иллюзии решения проблем проектирования и подготовки производства на базе какой-то одной, пусть даже мощной MCAD системы.