Користувач:РоманБуртник ПЗСм11

Реінженерія системи теплового проектування "Монстр"

Програмна система теплового проектування "Монстр" - система для моделювання нестаціонарних і стаціонарних теплових режимів в конструкціях гібридних інтегральних схем різного конструктивного та технологічного виконання, теплові моделі яких можна подати у вигляді багатошарового прямокутного паралелепіпеда з плоскими або навісними джерелами тепла.

Можливості системи

Програмна система МОНСТР дає можливість:

• Готувати вхідні дані за допомогою спеціалізованого графічного редактора.
• Контролювати правильність введених вхідних даних, візуалізуючи їх на екрані монітора.
• Розраховувати температури в центрах джерел тепла, в заданій сітці па площині Х, У ( у тому числі і між шарами в середині структури), а також в окремих вказаних точках багатошарової структури.

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

Технічні характеристики системи

Програмна система може застосовуватися як в середовищі MS-DOS, так і в середовищі WINDOWS.

Необхідний розмір оперативної пам'яті - 540 Кбайт.

Технічні засоби - ЕОМ типу ІВМ РС, Pentium з арифметичним копроцесором та графічним адаптером типу ЕGА, VGА та SVGА.

Максимальна розмірність задач:

• максимальна кількість шарів в структурі - 10;

• максимальна кількість елементів тепловиділення - 150;

• максимальна кількість членів ряду Фур’є - 30;

• максимальна сумарна кількість розрахункових точок за часом та координатах х, у, z - 3000 для кількості точок по часу не більше 1500;

• максимальна кількість точок дискретизації нижньої грані по координатах х, у 20*20;

Структура системи

До складу системи входять такі автономні програмні модулі

• препроцесор;
• процесор;
• постпроцесор.

Інформаційне забезпечення складається з бази даних та системи управління базою даних. В базі даних зберігається необхідна інформація для теплового моделювання: теплофізичні характеристики матеріалів конструкції, проектні дані для моделювання та проектні рішення та результати моделювання.

Препроцесор використовується для підготовки даних для теплового моделювання, наповнення бази даних, опису конструкції та топології, задання граничних умов, а також параметрів обчислювального процесу. В результаті роботи в препроцесорі над проектним завданням в базі даних формується розділ, який містить всю необхідну інформацію для теплового моделювання. Цей розділ буде використовуватися процесором па наступному кроці роботи з системою. Таким чином, препроцесором можна наперед сформувати і зберігати в базі даних декілька різних завдань на моделювання, кожному з яких присвоюється свій ідентифікаційний код.

Процесор програмної системи також підтримує взаємозв'язок з користувачем, дозволяє за іменем вибирати з бази даних існуючі проекти, в діалоговому режимі коректувати вхідні дані, виконувати задані обчислення, здійснюючи при цьому їх контроль візуалізацією за ступенем їх виконання, перевіряти і виводити для перегляду одержані результати розрахунку, а також записувати їх в базу даних для подальшого зберігання та обробки постпроцесором. В разі потреби (при незадовільних результатах, виявлених помилках або для модельних експерименті в) можна не виходячи з процесора змінити інформаційну модель і виконати повторні розрахунки, необхідну кількість разів змінюючи один або декілька вхідних параметрів. Процесор програмної системи дозволяє не лише здійсняти розрахунок теплового режиму, а провести модельні експерименти, здійснити пошук кращого проектного рішення, вибравши його з ряду існуючих варіантів. При цьому вхідні параметри змінюється в інтерактивному режимі, що дає гнучкість та ефективність модельних експериментів. Результати обчислень процесором подаються:

• в вигляді файлів - для передачі іншим суміжним системам проектування (схемотехнічне, конструкторське чи

технологічне);

• в вигляді твердої копії - для документування і тиражування результатів теплового проектування;

• в спеціальному внутрішньому форматі, зручному для візуального сприйняття проектувальником проектного рішення.

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

Актуальність системи

Задачі теплового проектування

Задачі теплового проектування технічних об‘єктів поділяються на дві групи:

• задачі прийняття схемотехнічних, конструкторських, технологічних рішень з урахуванням теплових обмежень;

• зворотні задачі теплопровідності, які виникають під час проектування технічних об‘єктів.

Такий поділ здійснено на основі виду й умов формування критеріальної функції. Для першої групи характерне формування критеріальних функцій при розробленні математичного забезпечення схемотехнічних, конструкторських, технологічних САПР. Результати аналізу теплових режимів виступають в ролі обмежень на критеріальну функцію і використовуються для формування області пошуку оптимального рішення. В загальному випадку задача формалізується у вигляді задачі векторної оптимізації:

визначити: Неможливо розібрати вираз (синтаксична помилка): {\displaystyle (x* ) ={x1*,x2*,…,xn*} }

що забезпечує: Неможливо розібрати вираз (синтаксична помилка): {\displaystyle minQ ̅(x ̅)}

за умови Неможливо розібрати вираз (синтаксична помилка): {\displaystyle x ∈Ropt}

де Неможливо розібрати вираз (синтаксична помилка): {\displaystyle (x^* ) ̅} : – вектор оптимальних значень варійованих схемотехнічних і конструкторсько-технологічних параметрів на відповідних етапах проектування; Неможливо розібрати вираз (синтаксична помилка): {\displaystyle Q ̅(x ̅)}  – вектор критеріїв оптимальності, які відповідають різним цілям за етапами проектування; Неможливо розібрати вираз (синтаксична помилка): {\displaystyle G ̅(x ̅ )} – вектор функції обмежень Неможливо розібрати вираз (синтаксична помилка): {\displaystyle g ̅(x ̅ )}  на параметри, які варіюються, і критеріальну функцію, які враховують тепловий режим технічного об‘єкта і його параметри.

Для розв’язання задач цієї групи формуються макромоделі температурного поля або використовуються спрощені моделі процесу теплопередачі, в яких змінними є параметри, що варіюються, а решта характеристик теплового режиму приймаються постійними для конкретної задачі й визначаються за допомогою аналізу загальної теплової моделі.

Розв’язання цих задач спрямоване на прийняття технічних рішень згідно з вибраною концепцією системи забезпечення теплового режиму, здійснюється вибір її проектних параметрів, уточнюються характеристики, які є результатом схемотехнічного і конструкторсько-технологічного етапів проектування. Основою оптимального теплового проектування є математична теплова модель (моделі) пристрою, який розробляється, і цільова функція, яка екстримізується. Модель зв’язує шукані проектні (причинні – з погляду постановки оберненої задачі) характеристики з параметрами, які описують тепловий стан об’єкта (наслідкові характеристики) і навантажувальними діями, наприклад, зовнішніми і внутрішніми тепловими потоками. Можливим варіантам проектно-конструкторських рішень відповідають визначені теплообмінні та геометричні характеристики конструкції технічних об’єктів.

Загальна характеристика нестаціонарних теплових режимів

При дослідженні стаціонарних температурних параметрів МЕП вважається, що потужність джерел тепловиділення Р є сталою в часі. Реально режими роботи елементів характеризуються значеннями прикладених змінних напруг і струмів. Відповідно, значення потужності тепловиділення також визначається змінними складовими. У багатьох випадках режими роботи МЕП є імпульсними (у вигляді періодичної послідовності імпульсів).

Крім того, в процесі проектування МЕП важливою для проектувальника є інформація про перехідні температурні процеси - вмикання та вимикання джерел тепловиділення.

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

Тобто, проведення аналізу нестаціонарних температурних полів є доцільним за таких умов:

• Необхідності визначити температурне поле МЕП в різні моменти часу після вмикання або вимикання джерела тепла.

• Необхідності розрахувати температурне поле при роботі елементів в імпульсному режимі (періодична послідовність імпульсів довільної форми).

• Необхідності врахування зміни в часі температури навколишнього середовища, тепловідводу або корпуса з врахуванням внутрішнього тепловиділення, на температурне поле МЕП. Є задача визначення

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

Залежно від тривалості та частоти імпульсів можливі такі режими:

• a)      тривалість імпульсу періодичної послідовності співмірна з часом нагрівання кристала (час встановлення стаціонарного режиму при перехідному процесі);

• b)      тривалість імпульсу періодичної послідовності є менша за температурну сталу кристала .

Потреба у реінженерії

Система "Монстр" працює на старих операційних системах (MS-DOS, Windows 3.11), а також була розроблена не раніше 1995 року, тому потребує реанімації, тобто реінженерії. Метою реінженерії є відновлення роботи системи на сучасних ЕОМ, а також створення можливості подальшого розширення системи,а також інтеграції її з існуючими системами теплового проектування.

Реінженерія програмного забезпечення

Реінжиніринг програмного забезпечення - процес створення нової функціональності або усунення помилок, шляхом революційної зміни, але використовуючи вже наявне в експлуатації програмне забезпечення. Процес реінжинірингу описаний Chikofsky і Кросом в їх працю 1990 року, як «The examination and alteration of a system to reconstitute it in a new form». Висловлюючись менш формально, реінжиніринг є зміною системи програмного забезпечення після проведення зворотного інжинірингу.

Реінжиніринг програмного забезпечення, можна розділити на кілька етапів:

Початкова фаза. Почати процес реінжинірингу слід з визначення того, що є по існуючій системі (вихідні тести, БД, описи і т. д.). При цьому фіксується поточний стан успадковане системи (всі зміни, що вносяться до неї після цього моменту, при виконанні реінжинірингу не враховуються). Якщо є можливість – виконується розгортання успадковане ПС у розробника.

Визначення системних архітектур. Роботи з опису архітектур починаються фактично на початковому етапі, коли визначається склад устаткування і стандартне програмне забезпечення (ПЗ), необхідні для інсталяції і запуску існуючої зафіксованої системи. Тим самим фактично визначаються архітектури БД, обладнання і стандартного ПЗ, телекомунікацій. Всі архітектури представляються в нотації UML і при необхідності доповнюються текстовими описами. Побудовані архітектурні моделі в процесі реінжинірингу будуть уточнюватися і доповнюватися.

Автоматичний реінжиніринг. Автоматичний реінжиніринг здійснюється за допомогою інструментальних засобів візуального моделювання. Його виконання дозволяє побудувати моделі, які можуть бути прийняті як вихідні. Автоматичного реінжинірингу піддається як бізнес логіка (якщо є вихідні коди на об'єктно-орієнтованому або об'єктно-базовані мовою), так і БД.

Редагування діаграм моделей. Моделі, отримані автоматично, досить складно читати і аналізувати, оскільки елементи моделі розміщуються без урахування наочності діаграм. Тому побудовані моделі повинні бути відредаговані. У процесі редагування не слід виконувати змістовні перетворення (видаляти або додавати елементи моделі). Головною метою редагування на цьому етапі є досягнення наочності діаграм. Для цього використовується переміщення елементів діаграм. У процесі редагування можуть вноситися коментарі до елементів моделі. Наприклад, можна прокоментувати призначення окремих класів. Коментарі заносяться до поля специфікацій елементів моделей.

Побудова функціональної моделі. Модель функціонування описується за допомогою діаграм ВВ і деталізують їх діаграм послідовностей і діяльностей. Джерелом для її побудови є працююча успадкована система і які проводяться з нею експерименти.

Визначення варіантів використання. Визначення ВВ виконується на основі аналізу екранів працюючої системи. Спочатку визначаються пакети ВВ. Для цього слід знайти всі первинні екрани і для кожного з них в моделі на головний діаграмі ВВ завести окремий пакет. Таким чином, на цій діаграмі буде пакет акторів і кілька пакетів ВВ. Далі виконується деталізація побудованих пакетів ВВ на основі аналізу екранних форм.

Визначення взаємодій акторів і ВВ. Оскільки дуже важливо показати, як актори співвідносяться з ВВ, після знаходження ВВ визначається, які актори взаємодіють з системою в цьому варіанті. У модель включаються асоціації. Вони мають напрямків, які відповідають напрямках передачі інформації між акторами і ВВ.

Розподіл по пакетах. Якщо число акторів або ВВ занадто велике, то для спрощення підтримки моделі ВВ доцільно розділити їх по пакетах. Це також спрощує розуміння моделі і розподіл відповідальності шляхом призначення розробників, відповідальних за пакети ВВ. Можна використовувати наступні критерії упаковки ВВ в один пакет:

Побудова навігації екранів. Одночасно з виділенням ВВ будується навігація екранів успадковане системи у вигляді діаграми класів UML. Кожен екран показується в моделі як окремий клас, в якому полях відповідають атрибути, функціональним кнопкам - операції, а кнопкам меню - однойменні відносини.

Деталізація функціональності. Деталізація функціональності є побудова сценаріїв реалізації ВВ, представлених в моделі ВВ. Вона виконується за допомогою діаграм послідовностей і діаграм діяльностей UML. Вибір виду діаграм в кожному конкретному випадку залежить від того, що переважає в даному ВВ - логіка виконання або передачі даних. У першому випадку переважно застосовувати діаграми діяльностей, де легко показувати розгалуження і паралельну обробку, у другому – діаграми послідовностей.[1]

Список використаної літератури

• Федасюк Д. В. Методи та засоби проектування мікроелектронних пристроїв. – Львів: Видавництво Державного університету «Львівська політехніка», 1999. – 228 с

• Koval V.A., Fedasyuk D.V. Multilevel Thermal Simulation of MCM's by System "MONSTR-M" // Proc. of the European Design and Test Conference (ED&TC' 95).- Paris (France).- 1995.- Р. 544-548

• Лобур М. Аналіз і постановка задач оптимального теплового проектування технічних обєктів./ Лобур М., Фармага І., Марікуца У.,Матвійків. – 2011

• Федасюк Д., Левус Є., Назар Ю. Система теплового моделювання кристалів ІС на жорстких виводах // Зб.наукових праць "Сучасні проблеми в комп’ютерних науках". – Львів. – 2000. – С.122– 126