Проблема автоматизації проектування в теорії систем

[ виправити ] текст може містити помилки, будь ласка перевіряйте перш ніж використовувати.

скачати

Федеральне Агентство з освіти РФ
Волгоградський Державний Університет
Факультет Управління Регіональної Економіки
Кафедра Математичних Методів та Інформатики в Економіці
Реферат
З дисципліни: загальна теорія систем
На тему: Проблема автоматизації проектування
Волгоград 2006

Зміст
Введення
Загальні питання автоматизації проектування
Висновок
Література

Введення

Термін "автоматизація проектування" розуміється дуже широко: тут йдеться про нову технологію проектування, заснованої на використанні ідей і методів системного аналізу. Об'єктами проектування можуть бути і технічні системи, такі, як літак, ракетний комплекс, корабель, і народногосподарські, економічний системи, наприклад системи облаштування великих нафтових або газових родовищ, використання басейнів, річок і т.д. Системний аналіз дуже широкий, і слова "автоматизація проектування" покликані його дещо звузити. Цей термін сьогодні все ж охоплює дуже багато різних за своїм змістом понять. Серед них є і суто технологічні: структура банків даних, засоби автоматизації графічних робіт, керуючі програми і навіть мови програмування. Центральним аналізованим тут питанням є проблема автоматизації початкового етапу, так званого аванпроектірованія. У цій проблемі основне наша увага буде зосереджена на виборі альтернативних варіантів при зав'язці проекту або створення генеральної схеми народногосподарського комплексу. Ця проблема є, ймовірно, не тільки найбільш важкою, але й вузловий проблемою проектування.

Загальні питання автоматизації проектування

Складність використовуваної і, головним чином, створюється техніки, складність використовуваних технологій, транспортних і виробничих зв'язків безперервно зростає. У цьому й полягає особливість епохи розвитку виробничої діяльності, яку зазвичай називають епохою науково-технічної революції.
Конструкції, які створюють інженери, все більшою мірою використовують знання, що видобуваються в суміжних науках. Об'єднання радіоелектроніки, теплових процесів, газової динаміки і багато чого іншого при створенні однієї конструкції є типовим для сучасного енергетичного машинобудування, ракетобудування, літакобудування. Різке ускладнення будь-яких виробничих зв'язків, технологій, перехід до нових матеріалів якісно ускладнюють роботу проектувальника виробничого комплексу, в результаті чого його сьогоднішня діяльність якісно несхожа на проектну роботу п'ятдесятирічної давнини.
Оскільки фізіологічні можливості людини обмежені, а складність створюваних конструкцій безперервно зростає, то очевидно, що одного дня ця теза перестає бути справедливим. В останні десятиліття ми починаємо все частіше стикатися з ситуаціями, коли головний конструктор або керівник проекту вже не може ефективно втручатися у процес проектування. З творця, творця конструкції він перетворюється, у кращому випадку, у хорошого адміністратора.
Тому на порядок денний висувається проблема принципової зміни всієї технології проектування - проблема автоматизації проектування. Її особливість - широке використання сучасних способів обробки інформації та подання її в такому вигляді, який дозволив би конструктору, проектувальнику до кінця використовувати свої творчі можливості. В останні роки цій проблемі приділяється все більше і більше уваги, причому таке явище характерне для всіх індустріально розвинених країн, що створюють складні зразки техніки і реалізують проекти найскладніших народногосподарських комплексів. Поступово автоматизація проектування стала однією з областей найбільш перспективного використання обчислювальної техніки і методів міждисциплінарних досліджень процесів різної фізичної природи.
Складний проект вимагає розчленовування процесу проектування на проектування окремих підсистем і агрегатів, поділу обов'язків між різними конструкторами, проектувальниками та дослідниками-розраховувача. Таке становище виникло вже давно: створення проекту літака, великої водогосподарської або технологічної системи - це завжди диференційований праця великого колективу.
Але розчленування проблеми необхідно передбачає і зворотний процес-процес об'єднання, узгодження характеристик окремих частин системи, синтезу, який дає можливість уявити конструкцію в цілому, оцінити її різноманітні якості та відповідність задуму.
Розчленування процесу проектування спочатку не викликало проблем. Візьмемо, наприклад, таку систему як, літак. Проектування планера природним чином відрізняється від вибору і проектування двигуна. Аеродинамічні і розрахунки на міцність роблять представники різних професій і т.д. Така ж ситуація спостерігалася всюди. І всюди поступово виникали традиційні форми поділу праці.
Тривалий час і процес синтезу проекту також не викликав особливих проблем: в міру ускладнення проектованих конструкцій удосконалювалися і методи проектування. Але з плином часу все частіше ці традиційні методи проектування стали давати збої. Перш за все, почали неприпустимо подовжуватися терміни проектування. Але це було б ще півбіди. Гірше те, що на випробування стали надходити конструкції, все менш і менш відповідають задуму, і у конструктора до початку випробувань не виявлялося можливості досить добре перевірити, наскільки створені ним машина чи технологічний комплекс відповідає задуму. У результаті - неминучі переробки, різке здорожчання конструкцій і подовження строків реалізації задуму до десятиліть. А це означає, що в вводиться конструкція (або технологія) вже застаріла, що відповідає технічному рівню мінімум десяти-двадцятирічної давності.
Аналізуючи ці явища, ми переконуємося в тому, що основні труднощі пов'язані з синтезом, з ув'язкою усього різноманіття особливостей майбутньої конструкції. Ці труднощі зростають експоненціально разом із зростанням розмірності, тобто кількості параметрів, які визначають конструкцію. Кваліфікація проектувальників тут мало чим може допомогти: традиційна технологія в принципі не може впоратися зі зростаючою складністю проекту, і треба міняти технологію проектування.
Виникнення і формування концепцій автоматизованого проектування відбувалося за наступною схемою. Спочатку почали автоматизувати креслярські роботи - цю дуже трудомістку частина будь-якого процесу проектування. З'явилися креслярські автомати. Вони, звичайно, виправдали витрачені кошти. Однак нічого принципово поліпшує проект або прискорює його закінчення вони не внесли, та й не могли внести. Одночасно йшло широке впровадження в практику інженерних розрахунків методів машинної математики. Ці методи суттєво вдосконалили різноманітні процедури проектних розрахунків, звели до мінімуму можливі помилки, підвищили загальну культуру проектування, однак також не привели до якого-небудь істотного скорочення термінів проектування.
Треба зауважити, що з використанням ЕОМ для проведення інженерних та планових розрахунків були пов'язані великі надії. Але вони багато в чому не виправдалися. Звичайно, в цьому була вина не ЕОМ, а фахівців, які ще не навчилися їх використовувати. З їх допомогою швидше і точніше вирішувалися окремі інженерні завдання, але серйозно вплинути на долю проекту, помітно прискорити закінчення роботи і поліпшити її якість вони ще не могли.
Наступний етап - створення автоматизованих робочих місць конструктора. Це - вже новий рівень мислення. Робочі місця виявлялися безпосередньо пов'язаними з ЕОМ, яка замінила конструктору традиційну лінійку або арифмометр, з'явилися найпростіші дисплеї, що дозволили конструктору реалізувати зворотний зв'язок з ЕОМ. Ідея автоматизованих робочих місць з'явилася в кінці 60-х років, одночасно з появою систем поділу часу. З їх впровадженням також було пов'язано чимало сподівань. І хоча ці надії далеко не всі виявилися виправданими, витрати на створення автоматизованих робочих місць, звичайно, цілком окупилися результатами. Ще одним важливим наслідком появи робочих місць було впровадження ідей діалогу ЕОМ-конструктор. Це була важлива характеристика певного етапу розвитку ідей автоматизованого проектування. До цих пір з ЕОМ працював математик - це він вирішував завдання, в яких потребував конструктор. Тепер же сам конструктор отримував можливість сидіти за терміналом електронної машини. Це не могло не позначитися на якості проектів.
Однак і автоматизація робочих місць конструктора, яка сталася в ряді країн на початку 70-х років, також не вирішила основної проблеми. Терміни між виникненням задуму конструкції та її реалізацією як і раніше залишалися значними. Конструкції, пропоновані до іспитів, вимагали в процесі випробувань численних і важких доробок, а часом і істотної зміни. У всіх тих ситуаціях, коли перевірочних випробувань не існує, наприклад, при створенні промислових комплексів, дефекти проекту могли обертатися часом трагедією. Та інакше і бути не могло, бо робочі місця конструктора-це лише частина загальної системи проектування.
Стала очевидною необхідність створення взаємозв'язаної системи проектування, що включає і систему програм для інженерних розрахунків, і автоматизовані робочі місця, і різноманітні діалогові процедури, і, звичайно, автоматизацію всіх графічних робіт.
Поки ще рано підводити підсумки, говорити про результати експлуатації таких систем і про їх ефективність. З їх введенням пов'язують великі надії, тому автоматизоване проектування переживає певний бум. Перш за все, для них необхідна вельми досконала обчислювальна техніка спільно з розвиненою системою її колективного використання. системи проектування, як вони замислюються сьогодні, вимагають колективного використання банків даних, систем моделей і програм. Їх експлуатація потребує великої кількості унікальних магнітних дисків, спеціальних наборів термінальних пристроїв і т.д. нарешті, створення спеціалізованого математичного забезпечення вимагатиме також багатьох років наполегливої ​​роботи численних колективів високої кваліфікації. Тому чекати швидкої появи повноцінних систем автоматизованого проектування не слід. Реально їх появу можна чекати в середині наступного десятиліття.
З цієї оцінки повинен бути один важливий практичний висновок: системи повинні створюватися з таким розрахунком, щоб вони могли вводитися в дію поступово, у міру готовності окремих елементів, блоків, тобто так, щоб експлуатація окремий частин системи могла починатися задовго до завершення всієї системи. Цей принцип дуже важливий, він дозволить заощадити не один мільйон рублів. Але його реалізація вимагає не тільки спеціальної організації програмного забезпечення але й спеціальної організації роботи користувачів-груп конструкторів і проектувальників.
Тепер щодо проблем діалогу. Сьогодні всі згодні з тим, що система автоматизованого проектування - деяка спеціальна діалогова система, що діалог людина-ЕОМ повинен займати центральне місце в процесі проектування. Але, на жаль, багато хто вважає, що організація діалогу не містить наукової проблематики і зводиться насамперед до вирішення суто технічних питань створення спеціальних термінальних пристроїв та гарного математичного забезпечення - пакетів програм для вирішення інженерних завдань. Це - глибока помилка. І якщо вона буде усунена своєчасно, то створення систем автоматизованого проектування може призвести до розчарування і неуспіху.
Необхідно створити спеціальну систему правил і алгоритмів, які складуть основу нової технології автоматизованого проектування складних об'єктів. Без створення нової технології системи автоматизованого проектування, подібно автоматизованим робочим місцям, будуть корисним інструментом, який вдосконалить процес проектування, але навряд чи внесе в нього ті зміни, які його якісно поліпшать.
Необхідно зробити кілька зауважень про "теорії" неформальних процедур і її застосування до проектування складних технічних конструкцій. Їх створення, подібних виробничому комплексу, літаку, електронній машині, - це перш за все творчий акт, і він не може бути ніколи до кінця формалізований. Цей факт ми будемо вважати аксіомою і з неї будемо виходити. Слід зауважити, що цілий ряд фахівців вважають, що акт творчості в проектуванні в значній мірі може бути замінений спеціально організованою системою обробки статистичного матеріалу. Статистична обробка параметрів існуючих конструкцій дуже важлива, і її в жодному разі не слід недооцінювати. Але її недостатньо, використання тільки одного статистичного матеріалу дозволяє створити конструкцію, лише має аналоги в окремих технічних рішеннях, тобто подібну вже існуючим. Дійсно оригінальні конструкції, що вимагають якісно нових технічних рішень, конструкції завтрашнього дня завжди вимагають нетрафаретного мислення, сміливості і таланту. Отримувати їх на основі статистики неможливо. Але прийнявши в якості постулату неможливість повної формалізації, треба зробити і наступний крок - зрозуміти місце і значення формальних методів, тобто методів, що використовують математичний опис вирішуваних завдань, зрозуміти, чим і як вони можуть бути корисні конструктору, як вони повинні бути об'єднані з неформальними процедурами.
При проектуванні складних конструкцій найважливішою є принцип поділу. Цей принцип - принцип декомпозиції - лежить, по суті, в основі всіх технологій проектування. І це легко зрозуміти, так як конструктор, як би талановитий він не був, може оперувати тільки з відносно невеликим обсягом інформації. Це розділення - декомпозиція - повинно бути пристосоване і до збірки - синтезу.
Це можна пояснити на прикладі літака. На вершині розглянутої ієрархії знаходиться головний конструктор машини, і перед ним стоїть проблема такого вибору параметрів, який би забезпечив вирішення завдань, поставлених замовником. Якщо мова йде про пасажирському літаку, то замовник-Міністерство цивільної авіації (ГВФ). Він хоче, наприклад, мати літак для грунтових аеродромів, який був би кращий за тих, які він сьогодні експлуатує, - ЯК-40, АН-24 і т.д. Якщо мова йде про винищувач, то замовник хоче мати літак, який був би краще існуючих винищувачів. Завдання так і повинна ставитися - це природна постановка на природній мові. Сформувати ж якийсь функціонал F (x), що залежать від усіх параметрів літака х, максимізація якого гарантувала б рішення задачі, ніякої математик чи конструктор не в змозі. Більш того, в реальності функціонал залежить не тільки від конструктивних параметрів літака, але і від великої кількості невизначених факторів уÎY, що характеризують середовище, в якій літак буде функціонувати. Таким чином F = F (x, y).
Тим не менш, для вирішення цього завдання ми можемо використовувати ідеї імітації. Розглянемо обидва типи літаків, про які йшла мова, спочатку обговоримо ситуацію з винищувачем. Припустимо, що ми створили систему, яка імітує бій двох винищувачів. Закладаючи в ЕОМ параметри проектованого і будь-який з існуючих літаків-винищувачів, ми розігруємо серію боїв нашого майбутнього літака з машиною, з якою ми збираємося його порівняти. У результаті набираємо необхідну статистику. Вона нам і покаже, який з літаків "краще". Мова йде про завоювання панування в повітрі. І якщо виявилося, що більша кількість боїв виграв проектований літак, то це і буде означати, що він краще існуючого. З літаком для цивільного повітряного флоту справа буде ситуація дещо складніша: там немає ніякої явної характеристики "якості" літака. Але провівши серію імітаційних експериментів, ми дамо можливість експерту, якщо ситуація відповідає гіпотезі компетентності, вибрати більш кращий варіант.
Значить, імітаційна система в принципі дозволяє порівнювати варіанти і відбирати найкращий. А це і означає можливість пошуку максимуму функціонала без знання його явного вираження. Однак це лише "принципова" можливість використання імітаційної системи як інструменту оптимізації. Імітаційна система-це, в принципі, машинний аналог випробувального полігону. Імітаційний експеримент на порядок дешевше льотного або будь-якого натурального експерименту. Але всього лише на порядок: використовувати імітаційну систему, так само як і систему льотних випробувань, для докорінного вдосконалення конструкції неможлива. імітаційна система-це насамперед інструмент перевірки, може бути, дуже незначного поліпшення. Створення імітаційної системи - ще не вирішення проблеми.
Значить, для справді ефективного використання імітаційної системи та всієї системи автоматизованого проектування необхідно враховувати той факт, що і головний конструктор володіє певними і цілком обмеженими психофізіологічними можливостями обробки інформації. Отже, необхідна декомпозиція проблеми. останнє означає, що потрібна система процедур, що дозволяє конструктору, і перш за все головному конструктору, оперуючи з обмеженою інформацією, вести спрямований пошук оптимальних параметрів конструкцій.
Деякі варіанти схеми проектування
а) Допоміжні функціонали, паретовскій аналіз. Обговорення процедур автоматизованого проектування почнемо з вищого рівня-рівня головного конструктора. Як вже було сказано, конструктор може мислити відносно невеликим числом параметрів І ці параметри, як правило, є агрегатами, тобто деякими функціями конструктивних параметрів літака причому <<N. У реальних умовах n ніколи не перевершує десятка, N-це багато тисяч.
Як випливає з досвіду організації та використання неформальних процедур, агреговані характеристики, якими мислить експерт, завжди досить індивідуалізовані. Але це не означає, що системи автоматизованого проектування повинні бути строго індивідуальні. Окремі блоки системи, загальна схема операційної системи САПР (системи автоматизованого проектування), структура банків даних, основна частина математичного забезпечення повинні бути стандартизовані. Але не може не братися до уваги той факт, що головний конструктор машини по-своєму думає про неї, має власні оцінки та критерії, відмінні від тих, які мав би інший головний конструктор.
Не слід, звичайно, і переоцінювати роль цього індивідуального елемента. Існує цілий ряд характеристик конструкції (літака, зокрема), які є загальноприйнятими. Наприклад, для літака максимальна швидкість, маневреність, стеля і т.д. Але, крім того, в залежності від характеру проектованого літака і особливостей мислення конструктора можуть виникнути й специфічні параметри. Наприклад, якщо мова йде про пасажирському лайнері або транспортному літаку, то може виникнути потреба в розрахунку міцності або економічних характеристик. Перебудова математичного забезпечення в цьому випадку не буде носити принципового характеру, оскільки ці характеристики практично завжди обчислюються в одному з блоків імітаційної системи.
Дуже важливо ще, щоб розрахунок агрегованих характеристик був досить простим, з тим щоб він міг бути проведений за допомогою математичного забезпечення, яке міститься в окремих блоках системи. Прикладом таких розрахунків є розрахунок тактико-технічних характеристик. Отже, перший етап декомпозиції полягає в призначенні деякого набору функціоналів, які, з точки зору головного конструктора, досить повно характеризують конструкцію, з тим щоб серед можливих варіантів відібрати ті, які будуть піддані подальшому аналізу. призначення цих функціоналів - акт неформальний, але на їх основі розвивається певний формалізм. Наступний етап-це виділення істотних змінних. Наступний етап-організація і використання процедур оптимізації, що є основою для побудови паретовского множини. Подальші процедури паретовского аналізу - вибір параметрів х, що реалізують компроміс:
Уявімо собі загальну схему процедур проектування на рівні головного конструктора.
Задаємо функціонали (Акт істотно неформальний).
Формуємо функціонал (Це-послідовність строгих процедур).
Будуємо функцію , Для чого в просторі будуємо сітку з вузлами і для кожного = вирішуємо завдання - Max.
Вирішуємо задачу і знаходимо "оптимальне значення" .
По заданому визначаємо параметри конструкції і переходимо до наступного етапу проектування.
б). Випадок, коли існує домінуючий функціонал.
До цих пір ми орієнтувалися на вивчення того випадку, коли немає формалізованого критерію, коли оцінка якості проекту - це суб'єктивно подання експерта. Була розглянута також ситуація, в якій можна скласти систему формальних процедур, які дають змогу вирахувати функціонал. Але обчислення цього критерію було настільки трудомістким, що його не можна було використовувати безпосередньо для визначення оптимальної системи параметрів конструкції.
Досить поширеним властивістю об'єкта проектування є існування деякого домінуючого функціонала, і весь аналіз конструкції повинен бути прив'язаний до вивчення варіантів в околиці його оптимуму.
Припустимо, що проект характеризується показниками а конструктор прагне вибирати параметри конструкції - вектор х - так, щоб забезпечити виконання умов . Позначимо через рішення задачі Нехай нове обмеження полягає в тому, що на вибір х накладено умову виду де 0 <k <<1. В якості функціоналу виступає зазвичай вартість проекту і вона не повинна перевищувати величини його найменшій можливій вартості на 100 k%. Визначивши мінімальну величину і систему параметрів - вектор , Який реалізує цей "оптимальний" проект, - ми обчислимо в точці інші характеристики: Вони повинні бути пред'явлені експерту, який буде свідомо незадоволений значеннями знайдених показників. Значить найдешевший проект повинен бути забракований. Він не буде задовольняти замовника за іншими показниками. Але від граничної вартості ми далеко відступити не зможемо, нас лімітують виділені гроші. Тому в околиці точки треба тим чи іншим чином побудувати сітку точок, яким відповідають близькі значення функціоналу . де в залежності від ситуації числа беруться рівними 0,01; 0,02; ... Потім обчислюються значення показників які пред'являються експертові, після чого з безлічі точок виділяється деяка підмножина варіантів для подальшого аналізу, а інші варіанти виключаються з розгляду.
в) Ще один приклад декомпозиції.
При реалізації процедури, описаної в попередньому пункті, ми неминуче зустрінемо одну складність, типову для будь-якого проекту, - розмірність задачі. Для цієї мети ввели "істотні" функціонали і "істотні" змінні, які дозволили від завдань, розмірність яких була близько багатьох тисяч, перейти до завдань розмірності десятка. пояснити сказане можна прикладом проектування системи облаштування нафтоносного регіону.
Припустимо, що мова йде про проект облаштування системи нафтових родовищ А, Б, В, Г, Д. які завдання має вирішувати проектувальник генеральної схеми? Перш за все у нього є конкретна мета - забезпечити виконання плану надходження нафти в центральний нафтопровід Цей план заданий даному регіону виходячи із загальних потреб країни в нафті у вигляді деякої функції де -Момент початку видобутку нафти, Т-кінець планового періоду. Завдання проектувальника полягає в тому, щоб визначити планові завдання виробництва окремих родовищ , Створити проект мережі нафтопроводів, що з'єднують родовища з центральним нафтопроводом, визначити черговість будівництва, намітити пункти збору і первинної обробки нафти, спроектувати систему закачування води для підтримки пластового тиску, спроектувати систему електроживлення і т.д. в результаті повинна бути видана документація на все необхідне обладнання, вся його специфікація, що включає тисячі найменувань. Все це безліч величин має бути вибрано так, щоб не тільки забезпечити виконання умови , А й досягти мінімуму вартості, тобто мінімуму функціонала , І, крім того, мінімізувати значення багатьох інших показників, які характеризують якість проекту.
Зрозуміло, складання проекту, вибір параметрів вимагатимуть визначеної ієрархії, проектування "по поверхах". Верхнім поверхом, очевидно, повинна бути генеральна схема, в якій кожне з родовищ виступає як окремий об'єкт. Але таке виділення верхнього рівня має сенс лише тоді, коли кожне з родовищ описується відносно невеликою кількістю параметрів. Але як це зробити, якщо кількість свердловин на більш-менш великому родовищі обчислюється тисячами? Очевидно, що без спеціальної форми агрегування, об'єднання величин тут не обійтися.
Спосіб агрегування підказує сама особливість завдання. оскільки кількість свердловин дуже велике, то замість розгляду окремих свердловин як самостійних об'єктів будемо розглядати їх як розподілу або, що те ж саме, вважати число свердловин на тому чи іншому родовищі безперервної і диференційовною функцією часу. Тоді зміна числа свердловин буде описуватися системою диференціальних рівнянь виду

де -Число свердловин на родовищі номери i, - Вектор ресурсу, виділений на розбурювання родовища номери i. Введемо величину -Дебіт окремої свердловини на родовищі номери i. Ця величина визначається багатьма факторами, але головні з них - це кількість свердловин і кількість вже здобутої нафти . Таким чином, закон зміни величини може бути параметризовані у вигляді Величина залежить ще від багатьох чинників: від способу експлуатації, від рівня того пластового тиску, що підтримується закачуванням води, і т.д. Але на верхньому рівні проектування, коли нам треба уявити собі лише загальні контури проекту, ми вважаємо, що всі ці фактори, вибір яких знаходиться в нашому розпорядженні, визначені деяким "оптимальним" чином.
г) Ієрархія рівнів проектування та буферні системи.
До цих пір ми обговорювали тільки процедури, які здійснюються на верхньому рівні проектування. У результаті ми зможемо одержати деякий ескіз майбутнього проекту. Безперечно, це найважливіший етап проектування. Підкреслимо паретовскій аналіз. Ми весь час розвиваємо ідеї діалогу, вся система процедур спрямована на одне: допомогти конструктору уникнути зайвої роботи, аналізу безперспективних варіантів, послідовно звужуючи безліч претендентів на рішення.
На наступному етапі починається проектування окремих частин літака: фюзеляжу, моторних відсіків, електрообладнання тощо Кожен з цих об'єктів сам по собі є досить складною системою і визначається великою кількістю різних характеристик.
Обговорюючи особливості процедур верхнього рівня, ми відзначили особливе значення системи конструкторських, проектувальних обмежень - безлічі Х. Це-квінтесенція інженерного досвіду та інженерної кваліфікації. Те ж саме треба сказати і про систему обмежень його агрегатів.
Припустимо тепер, що окремі літакові агрегати спроектовані. На цьому етапі можуть виникнути певні труднощі узгодження рішень, прийнятих на рівні головного конструктора і конструкторів, які проектують окремі частини літака. Конструктор фюзеляжу може не вписати свою конструкцію в жорсткі рамки обмежень по вазі виробу в цілому і по геометричних параметрах. Конструктор двигунів не зможе, наприклад, забезпечити необхідну залежність потужності від висоти або швидкості і т.д. Тому, якщо зібрати всі окремі технічні рішення в єдиний проект, то його вигляд буде дуже далекий від того, який представляв собі головний конструктор на самому початку.
Завершивши роботу над формуванням вигляду, тобто вибравши параметри х, ми вже можемо уявити собі вигляд літака з великим числом подробиць. Необхідна система різноманітних перерахунків. Ця система називається буферною системою. Наприклад, функціонали можна обчислити тепер набагато точніше, бо на другому рівні ми знаємо більшість величин і можемо розрахувати нові значення функціоналів де -Вже деякі відомі величини, а не нулі, як ми вважали при реалізації процедур формування вигляду.
Подібна система перерахунків дає можливість уточнити концепцію. Але можуть бути і інші системи перерахунків. Таким чином буферна система несе різноманітну навантаження. Вона дозволяє уточнити характеристики створюваної системи і служить засобом організації діалогу між проектувальниками.
Тут говорилося про проектування літака. По суті, все сказане зберігає свою силу і для автоматизованого проектування будь-якої складної технічної системи-корабля, ракетного комплексу, складною технологічною ліній, комплексного хімічного виробництва і т.д. Звичайно, структура алгоритмів і система критеріїв - все буде іншим. Але загальний підхід, розчленування проблеми, паретовскій аналіз, способи організації діалогу за допомогою імітаційної системи збережуть свою силу.

Висновок

Сьогодні автоматизація проектування, якщо її розуміти досить широко, - це один з найважливіших додатків системного аналізу. Було розглянуто 2 приклади проектування конкретних систем. Вони в деякому сенсі є двома головними випадками. Але тим не менш є багато спільного в проектуванні систем автоматизації. Це загальне дозволяє розглядати весь процес автоматизації як деякий, спеціальним чином організований, діалог. І організація діалогу людина-ЕОМ є головне в системах САПР. Показати, що діалог-це своєрідний алгоритм, побудова якого вимагає високого професіоналізму, показати, що це і є наріжний камінь всієї автоматизації проектування, - було головним завданням.

Література

1. Губанов В.А. та ін Введення в системний аналіз; Під ред. Л.А. Петросян. - Л.: Вид-во ЛДУ, 1988.
2. Каган М.С. Системний підхід і гуманітарне знання. - Л.: Вид-во ЛДУ, 1991.
3. Карташов В.А. Система систем: Нариси загальної теорії та методології. - М.: Прогрес-Академія, 1995.
4. Мойсеєв М.М. Математичні завдання системного аналізу: Учеб. Посібник для вузів. - М.: Наука, 1981.
Додати в блог або на сайт

Цей текст може містити помилки.

Програмування, комп'ютери, інформатика і кібернетика | Реферат
68.9кб. | скачати


Схожі роботи:
Проектування систем автоматизації
Технологічні аспекти теорії проектування інформаційних систем
Система автоматизації проектних робіт як обєкт проектування
Проектування таблиць для автоматизації обробки економічних даних
Проектування і дослідження засобів автоматизації інформації різного цільового призначення
Проектування АРМ співробітника відділу автоматизації інформаційного забезпечення Іванівського філії
Стадії проектування систем автоматизованого проектування
Проектування інформаційної системи збору даних землевпорядкування для автоматизації процесу оцінки
Екзаменаційні питання з теорії систем
© Усі права захищені
написати до нас