8(495)909-90-01
8(964)644-46-00
pro@sio.su
Главная
Системы видеонаблюдения
Охранная сигнализация
Пожарная сигнализация
Система пожаротушения
Система контроля удаленного доступа
Оповещение и эвакуация
Контроль периметра
Система домофонии
Парковочные системы
Проектирование слаботочных сетей
Аварийный
контроль
Раздел: Документация

0 ... 70 71 72 73 74 75 76 ... 96

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

Постепенный сдвиг в сторону подобных макетных систем наблюдается уже сегодня. В некотором смысле эти системы используются для интеграции всех функций разрабатываемой системы на максимально ранней стадии ее разработки. В основном такие средства уже присутствуют на рынке, однако они все же не обеспечивают возможности полного макетирования всех функциональных частей и узлов проектируемых технических систем в их конечном виде. Данная технология скорее будет применяться главным образом для выполнения многовариантного анализа типа «ЧТО БУДЕТ, ЕСЛИ ...»

Для решения подобных задач САПИР должна включать в себя всю информацию о технической системе, которую конструктор собирается создать. Например, для каждого из вариантов анализа типа «ЧТО БУДЕТ, ЕСЛИ ...» конструктор должен иметь в своем распоряжении соответствующую технологическую информацию, чтобы производственникам не пришлось в дальнейшем при освоении объекта в производстве дорабатывать и корректировать его проект. Исторически сложилось такая ситуация, что различные средства автоматизированного проектирования «понимали и воспринимали» лишь небольшие части полного проекта. Например, программа моделирования понимала один из видов описания проекта технической системы, а средства автоматизированного конструирования - совсем другой вид описания.

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


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

Такая «трассируемость» позволит конструкторам эффективно работать с разными вариантами представления проекта, с которыми ему приходится иметь дело при разработке любой технической системы. Если при описании проекта на различных уровнях иерархии обнаруживаются противоречия, то САПИР должна позволить конструктору их обнаружить и устранить.

33.4. Использование проектного опыта

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

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

Чтобы практически реализовать повторное использование проектных решений, обычные проектные библиотеки необходимо


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

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

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

Рис.3.15. Компьютерные базы знаний и их использование в проектах при реализации технических систем



0 ... 70 71 72 73 74 75 76 ... 96