CC BY
40
значит, невозможностью использования точных ал-
СИСТЕМЫ И ПРОЦЕССЫ і
УПРАВЛЕНИЯ
УДК 681.3.001
ТЕХНОЛОГИЯ СОЗДАНИЯ СИСТЕМ ПРИНЯТИЯ РЕШЕНИЙ КОНСТРУКТОРА РЭС
ГВОЗДИНСКИЙ А.Н., БЕНДИКОВ В.В._
Предлагаются технология создания систем принятия решений конструктора РЭС на ранних этапах проектирования и гибридная экспертная система (ГЭС), как основной инструмент этой технологии. Определяются задачи, решаемые ГЭС, описывается ее структура, намечаются пути реализации.
1. Введение
Современные радиоэлектронные средства (РЭС)— типичные представители сложных систем. Им присущи многомерность, иерархичность структуры, невозможность полной формализации как взаимосвязей между отдельными элементами и подсистемами, так и критериев оценки качества и эффективности, отражающих процессы в них. Поэтому при проектировании таких систем необходимо не только привлечение современных компьютерных технологий кон -струирования, но и разработка специальных методов структурной оптимизации, включающих элементы искусственного интеллекта. Решения подобных проблем показывают, что главной задачей, возникающей на всех стадиях проектирования, является создание “интеллектуального” блока принятия решений, основные функции которого выполняет экспертная система (ЭС). Технология создания таких систем, в тесной взаимосвязи с возможностями конструктора решать возникающие перед ним задачи, требует разработки специального инструментария и методологии.
2. Анализ состояния проблемы
Знания, которыми обладает конструктор РЭС, в большей части приблизительны, субъективны, являются результатом обобщения опыта и интуиции специалистов, и обычно представляют собой многообразие эвристических (эмпирических) приемов, правил, методик. Именно неточность используемых знаний определяет стремление на каждом этапе проектирования подтвердить и уточнить полученные решения. На ранних этапах таким средством являются моделирование, проведение расчетов, на поздних — испытания макетов и опытных образцов. Неформализованное^ отдельных подзадач, возникающих в процессе проектирования, вызывается также ограниченностью имеющихся ресурсов и,
горитмов решения.
Итак, очевидна проблема: с одной стороны, не-формализованность знаний и, следовательно, невозможность построения традиционных алгоритмов, с другой — стремление существенно сократить сроки проектирования и затраты на него, при этом улучшив качество разрабатываемой продукции. Данная проблема ненова и направление ее решения очевидно — выделить из общей задачи проектирования формализуемые (независимые или условно независимые) подзадачи, которые могли бы быть в дальнейшем автоматизированы. В настоящее время работа в этом направлении привела к тому, что эскизный проект практически исчез; расчетные программы, благодаря наличию графического интерфейса и успехам теории баз данных (БД), стали удобны в эксплуатации и приобрели элементы информационно-справочных систем. Кроме того, разработка электронных таблиц (например, Microsoft Excel [1]) позволила быстро автоматизировать свои расчеты неспециалистам в области программирования; САПР, например, ACCEL EDA фирмы ACCEL Technologies [2], позволяют осуществлять сквозное автоматизированное проектирование модулей на печатных платах от разработки принципиальных электрических схем до выпуска документации и управляющих программ для станков с ЧПУ. Программные комплексы, служившие первоначально для автоматизации чертежных работ, заметно расширили комплекс предоставляемых услуг, а благодаря внедрению технологий трехмерного проектирования, стали средствами моделирования (например, AutoCAD фирмы AutoDESK [1]). Отечественные производители расширяют возможности данных систем, создавая расчетные модули, средства автоматизации и моделирования, совместимые с указанными САПР информационно [3]; разрабатывают аналогичные системы с учетом требований ЕСКД [4]; улучшают решения отдельных подзадач, например, трассировки, моделирования модулей [5].
Использование САПР типа PCAD и AutoCAD при создании блока РЭС эффективно на этапах эскизного (если он выполняется) и технического проекта, т.е. после того, как выполнена “предварительная” работа, которой соответствует этап технического предложения (ТП) и которая предполагает необходимость анализа исходных данных на предмет их непротиворечивости и влияния на будущую конструкцию, выработки возможных гипотез (с проверкой их возможности), принятия окончательного принципиального решения, которое в дальнейшем и будет разрабатываться в среде, например, приведенных выше САПР.
3. Постановка задачи
В настоящее время задача ТП — не формализуема, поэтому традиционными методами программирования автоматизирована быть не может. На решение таких задач ориентированы методы инженерии знаний. Именно ЭС, используя вложенные в нее знания конструктора, способна создать множество “наилучших конструкций” и представить их в качестве рекомендаций лицу, принимающему решение (ЛПР).
Таким образом, объединяя известную неформализованную задачу проектирования РЭС и извест-
РИ, 1999, № 2
43
ный метод решения в виде ЭС (общей теории еще нет), мы получаем новую задачу — создать ЭС, автоматизирующую решение проблем этапа ТП конструирования блоков РЭС (целесообразно ограничиться “блоками”).
В основу предлагаемой технологии может быть положен метод синтеза модели конструкции блока в пространстве описаний элементарных типовых решений (ЭТР). Данный метод предполагает динамический (поэтапный, итерационный, с обратной связью, с выдвижением гипотез и отсечением неперспективных направлений поиска) процесс накопления знаний о создаваемой конструкции и содержит множество подходов, приемов, правил, моделей проектирования блоков РЭС на основе исходных данных. Основным положением предлагаемой технологии является утверждение о существовании нечетко выраженных сложных соответствий между исходными требованиями к конструкции и совокупностью ЭТР, их реализующих. Отметим, что ЭС не заменяет разработчика, а является частью системы конструктор-ЭС, призванной катализировать нахождение “оптимального решения” профессионалом. Именно эта идея поможет нам преодолеть проблему ограниченности вложенных в систему знаний и определить “поведение” ЭС.
Основным пользователем ЭС предполагается инженер-конструктор РЭС, т.е. специалист в данной проблемной области (ПО), хотя систему могут эксплуатировать, например, схемотехник или студент конструкторской специальности.
4. Задачи ЭС
Определим задачи проектируемой системы.
4.1. Разработать некоторое множество “наилучших конструкций” блока РЭС, удовлетворяющих требованиям ТЗ и возможным дополнительным ограничениям, определенных пользователем.
Блок РЭС — это множество взаимосвязанных некоторыми отношениями (в том числе и иерархическими) объектов радиоэлектронной области, рассматриваемое при производстве, эксплуатации, транспортировании и хранении как целое (такого определения здесь достаточно). Каждый объект (как и сам блок) имеет набор свойств, выделяющих его как сущность и (или) определяющих его отношения с другими объектами. Мы рассматриваем только те объекты (их свойства), которые в совокупности адекватно описывают процесс проектирования.
Каждый атрибут каждого объекта имеет область допустимых значений (ОДЗ). В процессе решения конструктор-ЭС производят означивание всех атрибутов системы. Ввиду неточности модели, данных, знаний и специфики решаемой задачи (оптимальное решение невозможно найти не только в отдельных подзадачах, связанных с выдвижением альтернатив, но и в конце этапа ТП в целом) в результате работы ЭС будет получено множество возможных конструкций блока. Понятие “наилучший” определяется оптимизацией некоторых эвристических функций и ЛПР.
Рассматриваемую задачу можно представить в виде совокупности условно независимых подзадач.
1. Ввод требований технического задания (ТЗ) на разработку конструкции блока. ТЗ — это единственный объект нашей ПО, все атрибуты которого означиваются пользователем и поэтому данные знания системы необходимо считать точными.
2. Анализ требований ТЗ — раскрытие ссылок на нормативно-техническую документацию, анализ электрической схемы каждого модуля и его элементной базы (выделение “особых” элементов), диалог с пользователем при неполноте знаний (например, о назначении отдельных элементов), получение справочной информации (СИ) для проверки требований ТЗ на непротиворечивость и сама проверка, логический вывод новых знаний о решаемой задаче (такие знания — неточны), формирование направлений поиска и расстановка акцентов в целевой функции.
3. Выработка дополнительных требований. Обычно конструктор ограничен в своих решениях (или он хочет ограничить ЭС в ее решениях) — ему необходимо дать возможность изменять ОДЗ любых атрибутов системы (при этом новые факты не должны входить в противоречие с полученными ранее).
4. Внешняя компоновка блока. Эта подзадача, предполагающая разработку вариантов размещения органов управления, индикации и т.п. на передней панели блока, определяется требованиями эргономики и дизайна. На данном этапе происходит создание множества, согласованного с ЛПР, вариантов.
5. Разработка модулей и частичных блоков. Здесь, на основании результатов предыдущей работы, рассчитываются возможные варианты. На данном этапе происходит выработка ограниченного множества альтернатив исполнения (с точки зрения реального производства такое ограничение — естественно), построенного на основе имеющихся типовых решений. Каждое полученное решение может накладывать различные ограничения на связанные с ним объекты.
6. Внутренняя компоновка и создание “оболочки” — размещение модулей (“больших” элементов, частичных блоков) в коммутационно-монтажном пространстве блока и разработка несущих и (или) корпусных элементов путем использования альтернатив, полученных из множества ЭТР, которые храниться в системе. Все однородные типовые решения системы ранжируются по обобщенному критерию пригодности. Величины последних определяются априорными значениями частных критериев, расставленными на предыдущих этапах акцентами, опытом, накапливаемым ЭС, ЛПР. Для ускорения поиска неперспективные решения отсекаются рассчитанным пороговым значением обобщенного критерия пригодности.
7. Формирование множества “наилучших конструкций” . Для каждого полученного решения проводятся расчеты, определяются частные и обобщенные критерии качества. Решение оптимизационной задачи позволит сформировать для ЛПР множество вариантов (в общем случае, это несколько решений).
4.2. Представление решений пользователю.
Ввиду роли, которую мы отводим ЭС в системе конструктор-ЭС, а также специфики ПО слово “решений” мы понимаем в широком смысле: это и
44
РИ, 1999, № 2
решения, получаемые ЭС на каждом шаге, и типовые решения, предлагаемые пользователю, и окончательные решения. Другими словами, пользователь должен активно участвовать в процессе разработки, для чего ему необходимо предоставить доступ к любой информации, имеющейся в системе: справочной, о типовых решениях, о текущих фактах, о долгосрочных знаниях. Более того, необходима обратная связь — всю эту информацию нужно организовать так, чтобы при решении определенных подзадач она вызывала в пользователе соответствующие ассоциации, активизирующие его творчество.
В связи со сказанным отметим, что:
— интерфейс должен соответствовать требованиям фирмы Microsoft для приложений под Windows95;
— накопленные системой факты, результаты расчетов, справочную и другую информацию пользователь должен иметь возможность легко найти, отобразить на экране и распечатать;
— при решении каждой подзадачи пользователю должна быть дана возможность легко изменять ОД 3 неозначенных фактов, набор альтернатив из предложенных ЭС и другую подобную информацию;
— ЭС должна уметь ответить на вопросы: “как она получила это значение?”, “какие варианты рассматривались? ”, “почему она задает этот вопрос? ”;
— разработанную конструкцию необходимо представлять графически, например, генерируя код и используя возможности системы AutoCAD (часть кода можно извлечь из использованных моделей ЭТР). Кроме того, это позволит создать базовый чертеж для дальнейшей работы.
4.3. Приобретение знаний.
Ввиду предполагаемого нами тесного взаимодействия ЭС и конструктора, знания о ПО будут распределены между обоими субъектами проектирования — этим мы снимем проблему ограниченности знаний вследствие невозможности их полного извлечения из эксперта [6]. Знания ЭС будут представлены в виде модели ПО (декларативные знания), множества продукционных правил (процедурные знания), БД СИ и ЭТР (декларативные знания), расчетных модулей, различного рода метазнаний. Система будет жизнеспособной только в том случае, если она позволит эксперту легко модифицировать свои БД (в том числе и правил) и будет самосовершенствоваться в процессе эксплуатации. Данные требования предполагают: наличие специального интерфейса между системой и пользователем для модификации баз правил, СИ и ЭТР, с возможностью удобного определения новых объектов, внесения изменений, просмотра, поиска, проверки непротиворечивости; независимость управляющих знаний и знаний о ПО (при сохранении модели последней неизменной); создание механизма изменения априорных характеристик системы вследствие накапливаемого опыта; сохранение “популярных” комбинаций ЭТР.
5. Структура системы и ее описание
Описав задачи ЭС, представим ее структуру.
Это должна быть ГЭС, использующая как неформализованные методы инженерии знаний и неформализованные знания, полученные от экспертов, так и
Пользователь
It
Эксперт
ІДЕ
Интерфейс
?пг
ж
Модуль
отчета
V.
I
Классическая ЭС
БД СИ
БД ЭТР
МО МПЗ
РП МЛВ БЗ
JA Модули расчетов
Структура ГЭС
формализованное знание, например, расчетные модули. Основными ее элементами, как видно из рисунка, будут: машина логического вывода (МЛВ); рабочая память (РП); база знаний (БЗ); модули — объяснений (МО), приобретения знаний (МПЗ), отчета, расчетов; Бд СИ и ЭТР; интерфейс.
МЛВ, используя факты РП и знания БЗ, формирует последовательность правил, применение которых к исходным данным даст решение задачи (фор -мируются текущие цели, определяется метод поиска, идентифицируется множество возможных для выполнения на данном цикле правил, разрешаются конфликтные ситуации, обеспечиваются механизмы совместного влияния правил, обратной связи и т.д.). В зависимости от состояния РП, МЛВ исполняет некоторое правило БЗ, или выбирает типовое решение в БД, запускает расчетные процедуры. МЛВ может быть организована в виде правил.
РП предназначена для хранения исходных, промежуточных и конечных данных проектируемого изделия. Это динамические декларативные знания о ПО (факты). Кроме них, РП содержит статические декларативные знания, не изменяющиеся в процессе решения задачи, — эти знания представляют собой модель ПО. Если представить знания РП в виде описанных соответствующим набором атрибутов множества объектов, адекватно представляющего область экспертизы (об этом была речь раньше), и дерева подзадач, то мы будем иметь необходимую модель. В процессе решения задачи все атрибуты получают конкретные значения (этот процесс начинается пользователем, когда он заполняет ТЗ), в дальнейшем ГЭС выводит новые факты из уже имеющихся на основании правил, заложенных экспертом в БЗ, или “советов” ЛПР. Отметим, что “новые” факты для РП — это новые значения для известных ГЭС атрибутов.
Для структурированной области естественно представлять факты сгруппированными по соответствующим объектам. Физически для этого удобно использовать реляционную БД, где незаполненная база служит моделью класса объектов данного типа, а каждая запись определяет конкретный объект (вариант исполнения) — экземпляр данного класса. Кроме значения факта, необходимо хранить дополнительную информацию, например, коэффициент
РИ, 1999, № 2
45
уверенности в его истинности; список правил, приведших значение этого факта в его настоящее состояние (это упростит объяснение полученных решений); список соответствующих ему правил (для повышения скорости).
БЗ в ГЭС предназначена для хранения долгосрочных данных ПО и правил, описывающих возможные преобразования этих данных. Что касается “долгосрочных данных”, то их мы будем хранить в виде модели области (см. выше), поэтому под БЗ мы понимаем совокупность преобразующих правил типа ЕСЛИ <условие> ТО <действие> [6]. Значение функции принадлежности, вычисленное для <условия> по правилам нечеткой логики, передается в качестве значения для функции принадлежности нового факта—этим учитывается неточность фактов. Так как сами правила преобразования носят эвристический характер, то вводится коэффициент определенности (КО) правила, определяемый экспертом. Таким образом, значение функции принадлежности нового факта может быть получено как произведение значения функции принадлежности <условия> и КО правила. Для учета информации, поступающей из различных источников, можно использовать, например, схему Шортлиффа или Байесовский подход [7]. Кроме самого правила, в БЗ будет храниться его имя, КО, описание (для объяснений), дата внесения, разработчик, признак о реализации или возможной реализации правила на данном цикле (или при решении данной задачи). Для оптимизации МЛ В правила могут содержать приоритет их выполнения. Физически правила, аналогично модели ПО, удобно хранить в виде БД — это позволит легко вносить изменения, получать объяснения и отделять МЛВ от БЗ.
МПЗ служит для автоматизации работы и предоставления сервисных возможностей эксперту (квалифицированному пользователю), осуществляющему модификацию БЗ, БД СИ и ЭТР. Кроме того, он осуществляет автоматический обзор конечных решений для подстройки априорных характеристик системы.
Получив некоторое множество “наилучших конструкций”, разработчику важно осознать, что они действительно “наилучшие”. Поэтому ему захочется узнать не только почему система остановила свой выбор на данном решении и увидеть всю накопленную информацию, соответствующую ему, но и, почему она отбросила то или иное решение или почему какое-то решение лучше другого; он может захотеть увидеть все рассматривавшиеся альтернативы. В связи с этим МО, используя список реализованных правил для соответствующего означенного факта, описание этих правил, обратную цепочку рассуждений (от <действия> к <условию>), информацию о положении на дереве подзадач, сможет не только удовлетворить пользователя, ответив на вопрос, но и, предоставив возможность изменить какое-либо из предшествующих <условий>, осуществить
возврат в проектировании (вплоть до ввода исходных данных) или выполнить поиск новых альтернатив.
БД СИ и ЭТР содержат декларативные знания из области конструирования РЭС, например, данные об элементной базе, материалах, типах модулей и схемах их размещения. Эти данные используются при анализе требований ТЗ, проведении расчетов, для формирования альтернативных решений. Для внесения изменений в эти БД необходимо использовать МПЗ.
Расчетные модули должны подтвердить (или опровергнуть) соответствие разрабатываемых вариантов требованиям ТЗ и определить множество технических характеристик, которые в своей совокупности будут в дальнейшем определять ее качество.
Модуль отчета служит для создания графической и текстовой документации на основании накопленной к настоящему времени информации о проектируемом системой конструктор-ЭС изделии.
6. Инструментальные средства
В качестве инструментальных средств разработки ГЭС можно выбрать объектно-ориентированный язык Borland Delphi Client/Server. Это язык создания современных приложений использует технологии визуального проектирования и позволяет разрабатывать БД. В дальнейшем (после отработки прототипа) возможно использование его объектных технологий для представлений знаний о ПО конструирования.
Литература: 1. Ключник И.И., Твоздинский А.Н., Бендиков В.В. Компьютерные технологии конструкторского проектирования РЭС. Лабораторный практикум. Харьков: УПИПЦ ХТУРЭ, 1999. 172с. 2. РазевигВ.Д. Система проектирования печатных плат ACCEL EDA 12.1 (P-CAD для Windows). М.: СК Пресс, 1997. 368с. 3. Кофанов Ю.Н., Зимненко И.А. Проектирование электронной аппаратуры с применением автоматизированной системы АСОНИКА / /Технология и конструирование в электронной аппаратуре. 1995. №1. С. 17-19. 4. Каскевич Н.В. Функциональные возможности САПР Базис-3.0 // Технология и конструирование в электронной аппаратуре. 1997. №4. С.17-19. 5. Филаретов Г.А., Шустерман Л.Б., Мазюкевич Т.В. Организация структуры критериев в задачах векторной оптимизации радиотехнических цепей и систем //Информатика. Сер. Автоматизация проектирования. 1993. №3. С.45-54.6. Попов Э.В. Экспертные системы: Решение неформализованных задач в диалоге с ЭВМ. М.: Наука. 1987. 288с. 7. Малышев Н.Г., Берштейн Л.С., Боженюк А.В. Нечеткие модели для экспертных систем в САПР. М.: Энергоато-миздат, 1991. 136с.
Поступила в редколлегию 03.04.99 Рецензент: д-р техн. наук, проф. Бодянский Е.В.
Гвоздинский Анатолий Николаевич, канд. техн. наук, профессор кафедры технической кибернетики ХТУРЭ. Научные интересы: методология оценки эффективности сложных систем. Адрес: Украина, 61166, Харьков, пр. Ленина, 14, тел. 40-94-94.
Бендиков Вадим Вадимович, аспирант кафедры технической кибернетики ХТУРЭ, ассистент кафедры конструирования РЭС ХТУРЭ. Научные интересы: автоматизация конструирования. Адрес: Украина, 61166, Харьков, пр. Ленина, 14, тел. 40-94-94.
46
РИ, 1999, № 2
