Почему же на сегодняшний день мы не имеем инструмента проектирования, хотя бы аналогичного тому, что имели 14 лет назад?

Причин тому, по-видимому, несколько. Безусловно, основное – необходимость очень больших затрат, которые мог позволить себе Советский Союз (без комментариев, хорошо это или плохо). В 1989 году мы одновременно использовали как ТЛП «КАЛИПСО» так и лицензионный AUTOCAD R10, при этом вполне осознанно рассматривая как элемент САПР только ТЛП, а AUTOCAD как инструмент черчения с возможностью удобной корректировки сделанного, в том числе и чертежей полученных с ТЛП. По чисто экономическим причинам за прошедшее время конкуренцию выиграли системы, ориентированные на визуализацию, как чертежную, так и натуралистическую. При всей их внешней «впечатляемости» (даже имея в виду большие сборки и появление ARX-объектов) по большому счету до САПР в части действительно АВТОМАТИЧЕСКОГО ПРОЕКТИРОВАНИЯ практически всем им «как до луны». Так может и не стоит беспокоиться – реальная жизнь отсеяла нереальные на сегодня идеи и все расставила по местам?

На наш взгляд, беспокоиться стоит, ради места под солнцем. Просто в данной области действует «эффект больших систем» – только при совместном развитии ряда элементов (список которых приведем ниже) можно будет получить СИСТЕМУ МАТЕРИАЛЬНОГО ПРОИЗВОДСТВА эры IT. Затраты же на разработку САПР, в традиционной, автономной постановке (как разрабатывалась ТЛП «КАЛИПСО»), по-видимому, уже не будут окупаемы никогда.

Авторы считают, что ни одна из компаний принципиально не сможет самостоятельно создать САПР уровня сложного изделия (самолет, стартовый комплекс, завод …), в то же время уверены в «практической потребности» таких систем. Ключ к разрешению противоречия в понимании того простого факта, что если мы хотим работать с информацией в общем виде (что и есть САПР), то должны быть готовыми воспринимать сложность модели любого объекта, адекватно сложности фактического объекта (фундамент здания, электродвигатель, человек-работник …), эта модель должна себя вести максимально подобно натуральному объекту. Отсюда вывод - модели объектов и процессов их преобразования должны описывать и размещать на своих сайтах те, кто лучше всех их знает, то есть производители и исследовательские организации (работающие с расчетными моделями). Эти доступные модели должны быть едины, но открываться в запрашиваемом понятийном срезе и с необходимой степенью детализации. Кроме того должна обеспечиваться рекурсивная ссылка на соответствующие аналогичные сайты с элементов входящих в состав модели. Таким образом, развитие могло бы идти при единстве дальних и ближних целей: в части ближних целей – производителям все равно необходимо публиковать на сайтах информацию о своей продукции и процессах сопутствующих ей; в части дальних – структура этой информации должна позволять также обращаться к ней из систем САПР по глобальной сети. При такой постановке на каждом уровне разработки САПР необходимо будет иметь дело с моделями объектов в большей степени уже готовых и, что очень важно, уже отлаженных. На наш взгляд, такую возможность сможет обеспечить модель в виде ассоциативного Лисп-списка.

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

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

Для этого 2-го класса материального производства сформулируем объективные предпосылки целесообразности инвестиций в развитие САПР в широком смысле этого понятия.

Известно, что судьба технических новшеств, как правило, проходит этапы типа:

• ЭТО прожектерство;
• в ЭТОМ что-то есть;
• ЭТО работает, но …;
• ЭТО само собой разумеется.

В 1993 г на семинаре в стенах ДПИ проектных институтов Минмашпрома, когда мы, в качестве головной организации САПР капитального строительства, излагали свое видение проблемы, общая реакция склонялась к начальной оценке по представленной шкале. Сейчас оценки сдвинулись, причем, благодаря разговорам о CALS, вплоть до высшей (ЭТО само собой разумеется), однако мы под «глобальной циркуляцией компьютерно ориентированной информации в процессе материального производства в течение всего инвестиционного цикла» понимали несколько большее.

С точки зрения неформального мышления часто полезнее ответить на вопрос "от противного", а именно, для чего НЕ НАДО вкладывать средства в развитие систем автоматизированного проектирования.

Их не надо вкладывать для:

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

Эти цели тоже не лишены смысла, но все они не могут по важности и минимально конкурировать с возможностью приблизиться к основной цели - СИСТЕМЕ МАТЕРИАЛЬНОГО ПРОИЗВОДСТВА эры IT.

Инженерный труд, как традиционно не связанный с торговыми операциями, оплачивался низко, сейчас тем более. Поэтому, за редким исключением, обоснование эффективности вкладывания средств в автоматизацию инженерного труда не выдерживает критики - барьер нищенской оплаты очень серьезен. Тем не менее, вложение средств и государственная поддержка развития систем автоматизации инженерного труда не просто целесообразны - они ЖИЗНЕННО НЕОБХОДИМЫ.

Почему? Рассмотрим пример развития материального производства. Пока строились здания типа простейшей хаты либо промышленное предприятие типа кустарной кузницы (т. е. простые объекты материального производства) - для их реализации достаточно было словесного описания "от отца к сыну". Появление технической документации на объекты материального производства было вызвано не стремлением конкурировать с методом "без техдокументации", а ПОЛНОЙ НЕВОЗМОЖНОСТЬЮ выполнить в натуре любой сложный объект, иначе, как разработав такую документацию. Т.е. в процессе человеческой эволюции материальное производство потребовало проекта (модели) ввиду следующего:

1. Сложности объекта - его полное представление во всех деталях одновременно не представляется возможным;
2. В связи с разделением труда, необходимо разным исполнителям давать разную, но взаимоувязанную информацию;
3. Еще до начала работ необходимо соотнести все необходимые ресурсы со своими возможностями и, при необходимости, откорректировать цель, (либо отказаться от нее вовсе - вспомним Робинзона, построившего лодку и не сумевшего ею воспользоваться);
4. Желательно проиграть варианты - что будет после реализации проекта;
5. Если объект выполняется "на заказ", то заказчик при помощи проекта подтверждает свои ожидания;

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

У авторов нет сомнения, что с точки зрения создания объектов материального производства в наши дни осуществляется ГЛОБАЛЬНЫЙ ПЕРЕХОД от бумажного описания объекта к определенным образом структурированной компьютерно-ориентированной информации. Основной вопрос – КАКОЙ И КАК ИМЕННО СТРУКТУРИРОВАННОЙ.

Можно с уверенностью сказать, что последствия такого перехода будут не менее глобальными для развития техники, чем в свое время появление техдокументации. Важно понять, что автоматизация инженерного труда, в результате которой другими (машинными) методами создавались бы те же бумажные документы – лишь промежуточный этап к подготовке предпосылок СИСТЕМЫ МАТЕРИАЛЬНОГО ПРОИЗВОДСТВА эры IT.

Именно ради этой КОМПЛЕКСНОЙ ЦЕЛИ и стоит вкладывать средства и осуществлять государственную поддержку развития соответствующих отраслей. Именно эта комплексная цель обеспечит не просто эффективность, а СОХРАНЕНИЕ вообще соответствующих производств, (также немыслимых сейчас без традиционной бумажной техдокументации, как через какое-то время - без компьютерно-ориентированнной).

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

На наш взгляд, сейчас уже есть определенное общественное понимание необходимости ГЛОБАЛЬНОЙ ЦИРКУЛЯЦИИ компьютерно-ориентированной информации в процессе материального производства и, при этом, на первый план встает вопрос - какой должна быть эта информация. Очевидно, она должна быть упорядочена, и уровень этой упорядоченности представляется минимально как электронное представление традиционных документов, максимально как некие электронные документы, соответствующие спецификациям CALS. Основная мысль статьи состоит в том, что этого мало.

Мы считаем, что принципиально «взрывной» эффект в развитии материального производства может дать следующая формула работы с информацией (аналогичная по важности формуле расположения игольного ушка у острия швейной машины):

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

Как мы пришли к мысли такой.

В 1989 году наш институт, получил первый десяток компьютеров с лицензионным Автокадом. По министерской кооперации осуществлялся обмен прикладными программными средствами, и мы попробовали одно из них, в котором можно было отрисовывать поперечные сечения стального проката в виде заранее заготовленных блоков, выбираемых из меню. Мы попытались решить эту задачу на основе Лисп-списков используя механизмы наследования, как данных, так и функций их обработки. На удивление быстро, нами была разработана первая версия прикладного продукта для работы с сортаментом стали - SRTM-среда. Стали очевидными принципиальные преимущества Лисп подхода к описанию объектов. Аналог, используя стандартные возможности AUTOCADа мог только отрисовывать поперечные сечения профилей. SRTM-среда (будучи объектно-ориентированной) за счет ряда механизмов, в том числе наследования, занимая в 20 раз меньше места на один профиль, позволяла НЕСОИЗМЕРИМО большее, а именно:

• отрисовывать не только поперечные сечения, но и боковые виды на профиль с 8-ми направлений, причем всё с динамически определяемыми степенями детализации;
• получать указанием мышью на сечение все геометрические характеристики профиля;
• захватив мышью несколько произвольно отрисованных сечений получать геометрические характеристики составного сечения (с фильтрацией захваченной области на объекты SRTM-среды);
• все возможности «ручного рисования» рассматривать как частный случай, среда ориентировалась на вызов ВСЕХ ее возможностей, в том числе и по выбору профилей для перенастраиваемых целей, из других Лисп-программ.

В дальнейшем мы развивали среду, что позволило отрисовывать 3-х мерные конструкции, рассчитывать на основные случаи нагрузок по СНИП, генерировать составные сечения множества топологий, автоматически выбирать из чертежа спецификацию стали и многое другое. Главное - в процессе развития постоянно сохранялась преемственность снизу вверх, рост среды шел естественно и безболезненно. О функции «спецификация стали» необходимо немного сказать особо. В начале 90-х мы планировали приобрести программу для формирования спецификации стали в одном из проектных институтов, она была написана на C, предусматривала ввод с использованием кодов профилей, кодов стали и вывод на принтер на листы А4. По разным причинам приобрести ее не удалось, и один из ведущих специалистов строительного отдела предложил нам написать свою программу формирования спецификации на основе SRTM-среды. Мы попробовали, имея в виду, что к тому времени уже была на Лиспе написана универсальная функция работы с табличными формами в чертежах. На удивление, все получилось довольно быстро. Благодаря ряду механизмов спецификация стали в SRTM-среде не только предоставляла больше возможностей, но и работала быстрее своего аналога.) Это оказалось возможным, благодаря тому, что в универсальную функцию табличных форм мы заранее (на всякий случай) заложили механизм «демонов» - программа отрисовывала таблицу (с автоматической разбивкой на листы), затем возвращалась, вычисляла и заполняла нужные поля. Механизм «демонов» на порядок упростил разработку, сократил ее сроки, сделал ее более интеллектуальной.

Опыт разработки SRTM-среды (прикладного продукта для работы с сортаментом стали) и возможность сравнения с аналогами не могли не открыть нам глаза на то, что Лисп-подход наиболее приспособлен для задач САПР просто по своей природе. Напомним слова Дж. Саммит «Все языки программирования можно грубо разбить на два класса. В одном находится ЛИСП, в другом - все остальные языки программирования». Кроме того, мы убедились в том, что проблема производительности труда проектировщика в последнюю очередь связана с быстродействием компьютеров, а в первую с принципами структурирования информации (как данных, так и функций обработки) и ее полнотой и актуальностью.

Впоследствии мы вполне осознанно, в соответствии с «Программой развития САПР капитального строительства» тогда Минмашпрома, занялись разработкой общего подхода к описанию объектов-моделей материального мира. Не можем не вспомнить с благодарностью людей осознанно поддержавших в те годы направление развития САПР на самом высоком уровне – Министра Минмашпрома г-на Черненко, Замминистра г-на Тимощенкова.

В этих разработках также разделялись дальние и ближние цели: в части дальних – формулировка своеобразного «списка - социального заказа развития» Государственным Деятелям – списка внешних целей, дающих эффект только при совместной реализации; в части ближних – разработка действующего прообраза структуры Унифицированных Моделей Объектов на основе фреймов-ассоциативных списков (мы назвали это ACE-технологией).

Этот «список - социальный заказ развития» состоит в прямом и косвенном поощрении на государственном уровне следующих факторов:

• Разработка структуры Унифицированных Моделей Объектов (УМО) материального мира и ориентация на них процедур технологического преобразования в натуре (обработка, сборка, отладка, тестирование …). В качестве прообраза такой структуры мы и разрабатывали АСЕ-технологию;
• Возможность при работе с УМО рекурсивного обращения к внешним специализированным УМО (например, по кондиционерам, или правилам пожарной безопасности, или признакам болезни…) по быстродействующим каналам связи;
• Постепенный перевод всех исполнительных технологических машин на возможность альтернативного слаботочного управления информацией, генерируемой УМО и передача УМО сигналов обратной связи;
• Постепенное создание и, главное, сопровождение всеми производителями и исследовательскими организациями специализированных УМО (изделия, нормы проектирования, расчетные модули, типовые серии, нормали …), связанные быстродействующей глобальной сетью.
• Поддержка разработчиков машинных методом проектирования в связи с объективной необходимостью отклоняться от существующих стандартов оформления документации.

Относительно ACE-технологии необходимо заметить, что в процессе использования различных программных средств опыт привел нас к мысли о том, что основное внимание отдельных разработчиков всегда было направлено на оптимизацию работы разрабатываемого им программного средства. При этом априори считалось, что в дальнейшем, при необходимости, удастся сделать переходники для стыковки с модулями других разработчиков. На практике эта стыковка – основное препятствие развитию больших систем. Мы попытались разработать вариант общего подхода к описанию любого объекта реального мира: станок, строительная конструкция, сам проектировщик, который ведет проектирование и т. д. Причем таким образом, чтобы эти описания могли посылать друг другу сообщения и автоматически реагировать на них, в том числе посылая сообщения другим объектам.

К 1997 году нам удалось создать первый работоспособный вариант ACE-технологии – системы взаимодействия Унифицированных Моделей Объектов (УМО). Эта технология характеризовалась следующими свойствами, заложенными в качестве базовых принципов:

• Ориентация на единую Лисп-среду (в связи с отсутствием подходящей Лисп-среды, имеющей развитые графические функции, первый вариант был выполнен на Автолиспе в среде Автокада еще 12 версии);
• Структурно все УМО представляли ассоциативные Лисп-списки. Часть ключей выделялась под системные нужды, например:
  • Внутренние и внешние имена фреймов, список дочерних фреймов, ссылка на родительские фреймы и механизм доступа к ним. Следует отметить, что в отличие от SRTM-среды в ACE-технологии уже использовалось множественное наследование, как объективно необходимое при полноценном проектировании;
  • Ключ списка характеристик данных (вывод текстовых значений, единиц измерений, смена языков, все виды справок по данному, границы допустимых значений и пр.);
  • Ключ списка «демонов», реагирующих на изменение соответствующих данных;
  • Ключ хранения «истории» фрейма;
  • Ряд прочих системных ключей.

Все прочие (несистемные) ключи считались понятийными и вычислялись по выражениям и данным, автоматически собираемым по всем путям наследования;

• Принципиально исключалось какое-то бы ни было разделение на программы и данные. МО (Модель Объекта) рассматривалась как аналог объекта реального мира, внешние воздействия на который изменяют его состояние. Ввнешние воздействия это посылка МО сообщений на изменение значений ряда свойств, запускающее механизм соответствующих «демонов», которые не только изменяют состояние МО путем изменения значения ряда других свойств, но и инициируют посылку соответствующих сообщений смежным МО;

(Например, во фрейм-УМО описывающий как объект здорового трезвого человека посылается сообщение на изменение понятийного ключа – процента алкоголя в крови, на это изменение автоматически запускается «демон», в зависимости от других понятийных значений изменяющий ключ веселости и ключ агрессивности и, кроме того, при превышении некоторых значений инициирующий посылку сообщения УМО-фреймам, описывающим партнеров этого человека).

• Объект проектирования, будучи отрисованным на чертеже, сохранял все свои свойства как МО, т. е. вел себя как живой организм, реагирующий на изменения характеристик;
• На всех этапах циркуляции УМО предусматривалось в качестве встроенных базовых возможностей:
  • Изменения по ходу работы, как языков диалога, так и изменение систем единиц измерения;
  • Изменение (в пределах прав доступа и границ данных) характеристик УМО, причем, с сохранением истории – кто, когда и что изменил. По истории можно было выйти на проектировщика как УМО (его фотография, адрес, №№ телефонов, E-mail …);
  • Доступ к справочной информации по УМО в виде текстов, слайдов, фильмов;
• В отличие от известных подходов, «демоны» не возвращали никаких понятийных значений, только интегральный результат-аналог реального мира (OK, Break, Repeat), что позволило встраивать очень эффективные механизмы проектных прерываний, и последующих продолжений с измененными параметрами, а также получать вовремя автоматические остановки при проектных «тупиках»
• Множество других интересных возможностей, например поиск с указанием имени наследуемого понятийного ключа в качестве критерия поиска.

Практический опыт разработки этой технологии дал нам ощущение выхода «на золотую жилу» и одновременно понимание невозможности серьезного успеха в этом направлении (ГЛОБАЛЬНОЙ ЦИРКУЛЯЦИИ компьютерно-ориентированной информации в процессе материального производства) без серьезной государственной поддержки. Стало очевидным, что САПР, работающая со сложным объектом, вообще не может быть создана в виде программы обрабатывающей данные – только моделирование объектов реального мира с механизмом посылки сообщений.

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

Разумеется, мы понимаем, что не обязательно во всем правы, но в главном – в том, что направление разработок по ГЛОБАЛЬНОЙ ЦИРКУЛЯЦИИ компьютерно-ориентированной информации в процессе материального производства требует широкого фронта работ с альтернативными подходами разных групп разработчиков, и это сейчас вопрос «выживания» экономик, сомнений нет.

Развитие последних лет, когда небольшие улучшения интерфейсов (безусловно, полезные) и минимальные элементы объектного ориентирования преподносятся как серьезный прогресс САПР и требуют колоссальных (для Украины) затрат на новые и новые версии, принципиально не ведущие к прорывным технологиям и, по большому счету, проектирующими системами не являющимися, если и добавляет уверенности в том, что в ближайшее время «жить станет лучше, жить станет веселее», то с атрибутом «не у нас».

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