Вступ
Сучасний стан розвитку світу радіоелектроніки, систем компютерниї технологій висуває перелік необхідних умов, які забезпечують успіх у використанні ЕОМ, при переході від ручного використання машин до автоматизованого проектування (САПР).
Найбільший ефект у проектуванні досягається, коли автоматизацією охоплені всі види розробки якого-небудь об’єкта, тобто коли створена крізна САПР. Розглядається структура такої системи і комплекс засобів, включений до складу всіх її підсистем. Обговорюється зміст компонентів цього комплексу.
1. Ручне та автоматизоване використання ЕОМ у процесі проектування
З моменту свого народження ЕОМ практично відразу стали використовуватися при розробці технічних систем.
На перших порах проектувальник повинен був зробити ряд підготовчих кроків перед виходом до ЕОМ:
- математично описати процеси у проектуємому об’єкті із заданою долею точності (тобто обрати модель об’єкта та скласти її рівняння),
- знайти метод вирішення рівняння та алгоритм розрахунків,
- записати цей алгоритм у вигляді програми
- ввести її в машину разом з чисельною інформацією.
Зрозуміло що все перелічене вимагало значного часу та значних зусиль. Тому таке використання ЕОМ, яке пізніше стали звати ручним, носило обмежений характер.
Але отриманий досвід вказував на великі можливості цього шляху, хоч і розкривав його значні недоліки.
Головний з них – необхідність фахівцю притягати до вирішення своєї задачі професійного програміста, або самому освоїти програмування.
І перше і друге не так просто реалізувати. Перший спосіб потребує значного числа програмістів.
Другий зв’язаний з великими втратами часу при оволодінні алгоритмічними мовами та прийомами програмування, причому ці затрати не виправдовуються внаслідок швидкої втрати навичок при відсутності регулярної практики.
Не дивно, що через деякій час з’являється інший засіб взаємодії розробника з ЕОМ, який отримав назву автоматизованого проектування. Суть його складається в наступному. Фахівцю не потрібно обирати модель об’єкту, складати рівняння, визначати чисельне рішення, розробляти алгоритм та писати програму.
Все це зроблено раніш при утворенні проблемно-орієнтованої програми.
В ній об’єднані кілька взаємодіючих програм, тому вона отримала ще одну назву – пакет прикладних програм (ППП). Пакет призначався для вирішення однієї проблеми, наприклад для аналізу лінійних електронних схем.
Ця проблема потребує послідовного вирішення ряда завдань, які можуть відрізнятися як постановою, так і методами.
Треба зауважити, що проблемно-орієнтована програма дозволяє фахівцю вводити до ЕОМ задачу в предметній формі, наприклад, у вигляді електронної схеми. Іншими словами, вхідна мова програми зрозуміла фахівцю (спеціалісту) і не потребує великих зусиль для його засвоєння.
Очевидно, ППП значно поширює коло людей, використовуючих ЕОМ в проектуванні, оскільки тепер знижуються потреби до рівня підготовки користувача в області програмування.
З іншої сторони, немає необхідності в збільшенні кількості програмістів, так як створений пакет експлуатується продовж певного часу без великих переробок та обслуговує багато користувачів.
В теперішній час є кілька подібних пакетів, призначених для аналіза електронних схем.
В якості прикладу назвемо такі програми: MICRO-CAP та ELECTRONICS WORKBENCH, DESIGN LAB, ORCAD 9.2, P-CAD 2002, MICROWAVE OFFICE 2000, SERENADE 8.5, ALPAC 7.6. Порівняння між собою деяких із перелічуваних та інших програм.
Проектування подібних програм це плід зусиль колективу, утвореного з програмістів різної кваліфікації та фахівців у сфері радіоелектроніки. При високій продуктивності групи розробників, складеної, наприклад, з 6 чоловік, програма середніх розмірів розробляється за 2 роки.
Поява проблемно-орієнтованих програм народжує передумову до переходу до системи автоматизованого проектування.
2. Система крізного автоматизованого проектування
Почнемо розмову про системи автоматизованого проектування, звернемось знову до рис. 1, хоч проектування передавача, підсилювача потужності та транзистора можна укласти в одну і ту схему, показану на рисунку 1, однак ясно, що зміст кожного елементу цієї схеми залежить від рівня, на якому знаходиться об’єкт проектування.
Відповідно і автоматизація його розробки буде проходити по-різному, як з точки зору змісту, так і потрібних зусиль. Тому для визначеності будемо вести мову про автоматизацію проектування вузлів передавача.
При розробці деякого вузла радіопередавального пристрою необхідно згадати про структурне проектування, схемотехнічне і конструкторсько-технологічне, як вже казали, найбільший ефект досягається при автоматизуванні усіх видів проектних робіт, що приведе до крізної, або інтегрованої САПР.
Її можна уявити в вигляді блока (рис. 1), на вхід якого надходить ТЗ, а на його виході отримуємо технологічну документацію для виготовлення розробленого вузла на виробництві.
Складається система з кількох підсистем, в яких проводиться автоматизоване структурне, схемотехнічне та конструкторсько -технологічне проектування.
Очевидно, якщо хоч в одній підсистемі немає автоматизації, то ця підсистема може стати вузьким місцем у всьому ланцюгу проектування, а система вже цілком не буде автоматизованою.
Розглянемо властивості САПР різного вида розробки, у тому числі й крізну. Насамперед всього відмітимо, що термін «автоматизована» система, а не «автоматична», використається не випадково.
Цим підкреслюється, що крізна САПР, як і інша її складова частина, виявляється об’єктом, в якій людина та ЕОМ взаємодіють на протязі всього процесу проектування.
У випадку автоматичної системи людина звертається до ЕОМ лише при введені даних та при отриманні результатів. В САПР із розумом, науково обгрунтовано розподілені функції між машиною та людиною: ЕОМ виконує проектні процедури, які вдається формалізувати, а людина – евристичні, творчі.
Важлива властивість САПР – її відкритість, тобто можливість внесення змін у систему, якщо відкритість не забезпечена, то економічно невигідно створювати САПР.
Насправді, розробка усіх елементів коштує багато і займає чимало часу. З іншої сторони, прогрес ЕОМ, обчислювальної математики та методів проектування створюють необхідність у безперервному обновленні деяких частин САПР. Це приводить до потреби відкритості.
Крізна САПР і відтворюючі її підсистеми складаються з кількох компонентів. Тому складові частини системи і використані в них програми повинні бути інформаційно узгоджені.
Це припускає єдину вхідну мову системи, а також взаємодію програм без втручання людини. Пояснимо останнє прикладом.
Нехай при проектуванні вирішуються дві задачі, одна з яких обробляється програмою А, а друга – програмою Б, причому початковими даними другої задачі являються результати розрахунків першої. Обидві програми будуть інформаційно-узгоджені, якщо результати з А передаються в Б автоматично. Сформульована властивість не тільки зменшує час розрахунку, але і оберіга від можливих помилок при передачі даних людиною.
Враховуючи, що читач має уявлення про САПР, завершимо параграф ствердженням: створення САПР ні в якому разі не потребує від фахівця – розробника безглуздого натискання кнопок у раніш визначеній послідовності.
Підкреслимо ще раз: проектувальник активно бере участь у розробці, за ним залишається вирішення задач, формалізація яких не досягнута, а також задач, яких він на основі своїх евристичних засобів вирішує ефективніше, ніж ЕОМ на основі своїх обчислювальних можливостей.
Щодо рівня підготовки фахівця-користувача САПР, то він повинен бути вище, ніж раніш. Дійсно, окрім знань із своєї предметної області йому необхідно засвоїти методику проектування за допомогою ЕОМ, куди входять цілий ряд питань, які раніш не вивчались:
точність методів розрахунку об’єкта проектування,
алгоритми цих методів,
оптимізація
можливості та таке інше.
Словом, все те, що дозволяє правильно експлуатувати САПР і грамотно формулювати розрахункові задачі для проектування з метою удосконалення цієї системи.
0 комментариев