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

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

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

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

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

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

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

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

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

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

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

1. Генерируют возможные варианты конструкторских решений.

2. Осуществляют оценку этих вариантов и выбирают лучший.

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

4. Моделируют принимаемые решения (в тех случаях, когда это возможно).

5. Оценивают соответствие выполнения принятых конструкторских решений намеченным целям.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 структурное проектирование (разработка структуры сложного технического объекта);

 схемотехническое проектирование (выбор и расчет комплектующих, расчет параметров, выбор элементной базы и т. п.);

 топологическая и весовая компоновка аппаратуры;

 разработка и согласование интерфейсов устройств и подсистем;

 разработка устройств, подсистем, алгоритмов и программ сложного технического объекта, их автономное тестирование;

 комплексное тестирование устройств, подсистем и программ сложного технического объекта и уточнение их интерфейсов;

 конструкторское проектирование.

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