Компьютерная поддержка принятия решений в САПР

Трахтенгерц Э. А.
Источник - http://www.osp.ru/ap/1997/05/27_print.htm

      Конструктор или ЛПР вынуждены исходить из своих субъективных представлений об эффективности возможных альтернатив и важности различных критериев. Эта субъективная оценка оказалась в настоящее время единственно возможной основой объединения разнородных физических параметров решаемой проблемы в единую модель, позволяющую оценивать варианты решений [2]. В этой субъективности нет ничего плохого. Опытные руководители и конструкторы хорошо осознают сколько личного и субъективного они вносят в принимаемые решения. С другой стороны, об успехах и неудачах большинства человеческих решений люди могут судить исходя только из своих субъективных предпочтений и представлений.

      Признанием фактора субъективности ЛПР или конструктора в принятии решения нарушен фундаментальный принцип методологии исследования операций: поиск объективно оптимального решения. Признание права на субъективность решения - есть признак появления новой парадигмы, характерной для другого научного направления - принятия решений при многих критериях [3].

      Однако при принятии решений по многим критериям существует и объективная составляющая. Обычно эта составляющая включает в себя ограничения, накладываемые внешней средой на возможные решения (наличие ресурсов, временные ограничения, экологические требования, социальная обстановка и т. п.). Многочисленные психологические исследования показывают, что сами конструкторы или ЛПР без дополнительной аналитической поддержки используют упрощенные, а иногда и противоречивые решающие правила [4].

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

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

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

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

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

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

      Термин "система поддержки принятия решений" появился в начале семидесятых годов [5]. За это время дано много определений СППР [6, 7, 8].

      Так в работе [6] она определяется следующим образом: "Системы поддержки принятия решений являются человеко-машинными объектами, которые позволяют лицам, принимающим решения, использовать данные, знания, объективные и субъективные модели для анализа и решения слабоструктурированных и неструктурированных проблем". В этом определении подчеркивается предназначение СППР для решения слабоструктурированных и неструктурированных задач.

      В соответствии с работой [9] к слабоструктурированным относятся задачи, которые содержат как количественные так и качественые оценки проблемы, причем качественные имеют тенденцию доминировать. Неструктурированные проблемы имеют лишь качественное описание.

      Человеко-машинная процедура принятия решений в САПР с помощью СППР представляет собой итеративный процесс взаимодействия конструктора и компьютера.

      Системы поддержки принятия решений в САПР:

1. Генерируют возможные варианты конструкторских решений.
2. Осуществляют оценку этих вариантов и выбирают лучший.
3. Обеспечивают постоянный обмен информацией между конструкторами о принимаемых ими решениях и помогают согласовывать групповые решения.
4. Моделируют принимаемые решения (в тех случаях, когда это возможно).
5. Оценивают соответствие выполнения принятых конструкторских решений намеченным целям.

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

      На рис. 1 [10] показан фрагмент возможной структуры системы распределенного автоматизированного проектирования сложного технического объекта применительно к проектированию электрооборудования подвижного объекта, на котором мы и будем иллюстрировать предлагаемый подход. Система содержит 7 блоков.

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

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

      В этом случае средства групповой обработки данных (см. разд. 4) обеспечат конструкторам возможность оперативной оценки правильного выбора исполнительных агрегатов и элементов.

      Заметим, что в блоке 2 нет изображений дисплеев с клавиатурой. Это значит, что он может функционировать автоматически, без вмешательства конструктора.

      В блоке 6 аббревиатуры означают: РАБ - распределение аппаратуры по блокам, КПБ - компоновка приборных блоков, КС - компоновка стеллажей, РПО - разработка программного обеспечения.

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

      1. Комплексная (сплошная) автоматизация проектирования от разработки структуры проектируемого объекта до выдачи рабочих чертежей и даже доведения проектируемого объекта до серийного производства.

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

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

      Наконец, отсутствие системы автоматизации проектирования отдельных компонент сложного технического объекта может создать "узкие места" при проектировании объекта, а ухудшение качества проектирования этих компонент может резко ухудшить характеристики всего объекта. Примером могут служить часто возникающие сложности при разработке программного обеспечения.

      2. Увеличение числа прорабатываемых вариантов проекта на всех уровнях проектирования.

      При "ручном" проектировании (без применения вычислительной техники) в тех случаях, когда есть возможность синтезировать оптимальные проектные решения (например, при определении контуров летательного аппарата), они синтезируются, но в отдельных случаях, например, при трассировке проводов или компоновке блоков реле, как правило, выбирается первое допустимое решение, удовлетворяющее всем ограничениям и достаточно хорошее с точки зрения проектировщика.

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

      Это особенно важно на начальных стадиях проектирования, как например, при выборе топологической и весовой компоновки бортовой аппаратуры летательного объекта, определении характеристик отдельных подсистем и т.д.

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

      3. Возможность сравнения вариантов проектирования и выбора наилучшего из них с помощью подсистем оценки вариантов решений СППР.

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

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

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

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

      4. Эффективное создание программного обеспечения

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

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

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

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

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

      6. Логическое и временное тестирование проектов аппаратных средств и программного обеспечения.

      Эта задача не принадлежит к функциям СППР.

      7. Выдача рабочей документации и/или программ для станков с ЧПУ и гибких производств.

      Эта проблема широко обсуждалась в литературе, ее важность в настоящее время очевидна, поэтому в комментариях она не нуждается.

      8. Наконец, последнее по счету, но отнюдь не по важности - система должна обеспечить возможность параллельной работы всех конструкторов, участвующих в проектировании объекта.

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

      Место системы поддержки принятия решения в САПР проиллюстрируем на примере создания программного обеспечения. Для иллюстрации связи между требованиями к технологии распределенной САПР и ее программным обеспечением рассмотрим общую схему системы автоматизированного проектирования.

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

      Схематично можно выделить следующие подсистемы САПР (естественно, может быть предложен другой вариант):

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

      На этом процесс собственно конструирования заканчивается. Продолжением процесса конструирования является технологическая подготовка производства, изготовление и испытания сложного технического объекта, которые в последнее время объединяются в одно целое (например, система MAP/TOP [12]).

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

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

      I. Групповая обработка данных (для реализации требований 1, 5, 8 в структурах проектирования A - G).

      II. Подсистема генерации (экспертные системы) проектных решений аппаратных и программных средств (для реализации требований 1, 2, 3, 5, 6, 7, 8 в структурах проектирования A, B, E, F).

      III. Подсистема тестирования проектных решений аппаратных и программных средств (для реализации требований 1, 2, 3. 5, 7, 8 в структурах проектирования A, B, E,F).

      IV. Подсистема оценки проектов (для реализации требований 1, 2, 3, 5, 8 в структурах проектирования A, B, C, D, E).

      V. Подсистема согласования решений и принятия групповых решений (для реализации требований 1, 2, 3, 5, 8 в структурах проектирования A, B, C, D, E).

      VI. Подсистема моделирования функционирования проектируемых объектов и их тестирования (для реализации требований 1, 3, 5, 6, 7, 8 в структурах проектирования A, B, C, E, F).

      VII. Компьютерные графические подсистемы (для реализации требований 1, 7, 8 в структурах проектирования A - G).

      Уже из обсуждения возможной структуры САПР, вырисовывается состав компьютерной подсистемы поддержки принятия решений в системе автоматизации проектирования. Это блоки II, IV, V, и частично блок VI.

      Схема функционирования компьютерной системы поддержки принятия решений в САПР представлена на рис. 2. Номера блоков показывают последовательность процесса принятия решений, стрелки обратной связи - цикличность процесса.

      Заметим, что на рис. 2 из блока 2 возможен переход как в блок 3, так и в блок 4. Переход в блок 4 означает, что согласование решений не производится.

      Легко установить соответствие между некоторыми блоками третьего столбца таблицы и блоками рис. 2.

      Блок II соответствует блоку I (рис. 2), блок IV - блоку 2, блок V - блоку 3, блок VI - блоку 5.

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

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

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

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

      Информация, представляющая интерес для нескольких участников группового принятия решений, располагается в "общих" окнах. К этой информации имеют доступ все участники группы. "Общие" окна создаются по принципу WYSWIS (what you see is what I see - что видишь ты, то вижу я).

      Большинство существующих в настоящее время систем поддержки принятия решений базируются на двух технологиях, обеспечивающих передачу текста и графики - это телекоммуникации и базы данных. Использование средств мультимедиа добавляет третью составляющую - виртуальную реальность [14], так как словесное, табличное и аналитическое описание, а также представление в виде чертежей, не всегда являются адекватным. И хотя запахи и консистенция объекта еще не могут передаваться по электронным системам, но передача звуков и подвижных образов - вполне доступна. При оценке шума двигателя, передача звука во многих случаях намного выразительнее, чем данные звукометрии, а взаимодействие отдельных частей устройства лучше всего проследить на трехмерных динамических моделях. Так при проектировании самолета GULFSTREAM V электронный макет позволил конструкторам проверять форму, размер и сопряжение деталей, как если бы они были изготовлены. Соответственно в процессе моделирования были согласованы и разрешены все вопросы, связанные со стыковкой отдельных устройств и частей самолета [15]. Применение средств мультимедиа совершенно изменило процесс моделирования.

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

      Генерацию возможных решений можно реализовать посредством: программной реализации аналитических моделей, с использованием экспертных систем, генерации сценариев путем комбинации различных операций, заданных конструктором или взятых из базы данных, и, наконец, используя подход, получивший название ситуационного управления [16-22].

      Остановимся на экспертных системах и на них покажем структуру систем поддержки принятия решений в САПР. Экспертная система, используя знания, полученные от специалистов в данной предметной области, решает те же проблемы, экспертами в которых являются эти специалисты.

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

      Для всех наиболее успешных применений экспертных систем характерна по крайней мере одна общая черта - они работают в одной ограниченной предметной области знаний. Попытки расширить предметную область, даже в пределах одной области знаний (например, в медицине), в подавляющем большинстве случаев успеха не давали [23].

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

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

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

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

      На рис. 3 и 4 [22] показаны примеры распределенных экспертных систем САПР, генерирующих конструкторские решения. Экспертная система распределена функционально, то есть включает различные экспертные системы, но все они могут находиться в одной вычислительной системе.

      Экспертная система, показанная на рис. 4, распределена как функционально, так и пространственно. Фактически это группа экспертных систем.

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

      Процесс проектирования отдельных устройств и подсистем, заключающийся только в последовательности операций проектирования этих объектов (без согласования решений), представлен в виде дерева на рис. 4. Прямоугольник обозначает проектируемый объект. При его проектировании используется одна или несколько экспертных подсистем, аналогичных показанным на рис.3. Блоки, показанные объемно, обозначают, что одновременно могут разрабатываться несколько однотипных устройств, например блоков реле. На рис. 4 обозначены также выходная документация и средства редактирования полученных проектных решений при работе в интерактивном режиме.

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

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

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

      На рис. 5 показан фрагмент возможной схемы проектирования подсистемы оборудования летательного аппарата. Он отличается от рис. 4 тем, что в него включены блоки согласования проектных решений, являющиеся элементами СППР (на рис. 5 не показаны средства редактирования решений и выдачи документации). Таким образом дерево (рис. 4) превратилось в сеть. Экспертная система (рис. 5) - уже элемент распределенной СППР. В ней возникает новый элемент СППР - подсистема согласования решений.

      На рис. 6 дана обобщенная схема в СППР проектирования летательных аппаратов, включающая в себя подсистемы генерации, согласования и выбора решений с использованием системы групповой обработки и общей базы данных. Естественно, каждая подсистема (внешних связей, двигателей и т.д.) развертывается в СППР, типа тех, что показаны на рис. 3, 4, 5.

      На рис. 6 видно, что распределенная система группового проектирования представляет собой иерархическую подсистему поддержки принятия решений в распределенной САПР с высокой степенью параллелизма работы конструкторов. Точками синхронизации параллельной работы являются блоки согласования проектных решений по проектам стыкуемых объектов.

      На рис. 6 показаны экспертные системы, генерирующие варианты конструкторских решений. Автоматическая генерация различных вариантов может быть осуществлена различными способами: перебором вариантов компоновки, заложенными в экспертную систему, варьированием значений коэффициентов уравнений, предусмотренным алгоритмом расчета, порождением вариантов конструкторских решений на основе анализа возможных комбинаций элементов конструкций и т. д. [17, 19, 21, 24-27].

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

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

      Основная особенность современного моделирования - это визуализация.

      Вот как описывается визуализация процесса моделирования в работе [20]: "Опора линии электропередач вздрагивала и вибрировала по мере усиления ветра. Когда его скорость превысила 90 км/ч отклонения стали заметны на глаз. Когда скорость ветра превзошла 240 км/ч, опора начала извиваться в причудливом танце. Провода порвались. Одна из растяжек лопнула и мачта согнулась пополам".

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

      На рис. 6 показаны блоки оценки и согласования конструкторских решений.

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