Пильов В.О., Шеховцов А.Ф. Двигуни внутрішнього згоряння: Серія підручників. Том 4. Основи САПР ДВЗ

Подождите немного. Документ загружается.

боти програми. Наприклад, забезпечення певного рівня міцності деталі КЗ

може бути досягнуто за рахунок зміни геометрії, матеріалу, умов теплооб-

міну. Вибір конкретного способу або комплексного рішення по забезпе-

ченню міцності конструктор приймає в процесі проектування.

Ще більшу свободу вибору має конструктор при виконанні креслень.

У даному випадку задача формулюється так: за

поданим набором скінченої

кількості графічних примітивів та скінченої кількості команд роботи з ци-

ми примітивами отримати креслення або (і) тривимірну модель деталі. Бе-

зумовно, що виконання конструкторського опису деталі тут здійснюється

шляхом послідовної реалізації проектних операцій та дій, які залежать від

вже виконаних дій, складності деталі, що проектується, досвіду проектува-

льника. При цьому результати послідовно виконаних дій потребують по-

стійного візуального контролю.

Мови керування і супроводу необхідні для безпосередньої

взаємодії проектувальника з ЕОМ у процесі отримання

проектного рішення.

Мови керування необхідні для подання інформації, що управляє по-

дальшим виконанням проектних операцій і дій. Словниковий запас і гра-

матика мови керування повинні співпадати з мовою опису завдань. Мови

супроводу використовують для корегування або введення даних у процесі

виконання проектних процедур. Їх словниковий запас та граматики пови-

нні збігатися з мовами

опису об’єктів.

Мови керування і супроводу в своєму складі повинні мати також мо-

ву діагностичних помилок і елементи вихідних мов. Наприклад, мовою ке-

рування подано команду штрихування незамкненої області або мовою су-

проводу задано від’ємний радіус кола. В таких випадках про завдання по-

милкової інформації система повинна повідомляти

користувача.

У зв’язку з тим, що загальне керування роботою програмних ком-

плексів підтримує ОС, помилки можуть виникати в процесі роботи самої

ОС: принтер відключений або відсутній папір; не вистачає розміру віртуа-

льної пам’яті; певний файл редагувати або знищувати заборонено; не мож-

на знайти комп’ютер в мережі тощо. З

цього приводу ОС має власну мову

діагностичних помилок. Класичні приклади дії мови діагностичних поми-

лок подано на рис.4.7.

190

Внутрішні мови. Виведемо на екран за допомогою редактора текстів

зміст файла Porsh_h.cdw, в якому зберігається складальне креслення по-

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

ло виконано в графічному редакторі системи КОМПАС та яке вдається ви-

вести на друк, в згаданому файлі відсутнє (фрагмент змісту файла

Porsh_h.cdw

у вікні текстового редактора наведено на рис.4.8).

Завантажимо цей файл до графічного редактора системи КОМПАС –

зображення з’явиться. Це добре видно з рис.4.9. Тепер виконаємо спробу

завантажити наданий файл до іншої системи інженерної графіки, напри-

клад Solid Works. Отриманий результат подано на рис.4.10. Видно, що сис-

тема Solid Works за допомогою мови діагностичних помилок вказала

на

неприпустимість цієї операції.

Таким чином, різні програмні комплекси, навіть одного призначення,

оперують різним внутрішнім описом інформації. Тут передбачається, що

специфіка опису внутрішньої мови повинна відповідати максимальній

ефективності використання конкретних програм.

Внутрішня мова призначена для ефективного подання

інформації на певних стадіях її програмної обробки в процесі

автоматизованого проектування.

исунок 4.7 – Приклади

дії мови діагностичних

помилок ОС:

а – б – варіанти реакції

ОС на помилк

191

исунок 4.8 – Результат завантаження файла креслення поршня

шат

ном Porsh

h.cdw в

едакто

текстів Блокнот

исунок 4.9 – Результат завантаження файла креслення Porsh_h.cdw

в графічний редактор КОМПАС

192

исунок 4.10 – Реакція системи SolidWoks на завантаження

файла креслення Porsh_h.cdw

Розглянемо роботу окремих модулів графічної системи та їх взаємо-

дію з даними. Відповідно до рис.4.11 конструкторський опис об’єкта про-

ектування виконується в графічному редакторі (блок 1) шляхом надання

команд мовами керування і супроводу. Отримані дані формуються систе-

мою на внутрішній її мові (блок 2). Надалі звертання до цієї мови з різних

модулів

системи приводить до подальшого редагування інформації (блок

1), розгляду результату редагування на екрані (блок 3), виведення зобра-

жень на паперові носії (блоки 4,5). При цьому граматика внутрішньої мови

повністю визначається вимогою максимальної ефективності переробки ін-

формації в певній підсистемі САПР з метою мінімізації часу відклику сис-

теми на запит користувача.

Ко

ист

вач

ови

керування і

супроводу

Мовний

постпроце

сор

Мовний

перед-

процесор

Підготовка

креслення

до друку

на принтері

креслення

до виведення

на плоттері

Підготовка

Розгляд

креслення

на екрані

Конструкторський опис

об’єкта проектування

внутрішньою мовою

графічної системи

Графічний

редактор

в’язок з іншими

підсистеми САПР

проміжною мовою

Вихідна мова

ОМ

исунок 4.11 – Схема взаємодії графічної системи із зовнішнім середовищем

193

Таким чином, кожна окрема підсистема проектування чи обслугову-

вання обробляє інформацію з максимальною ефективністю, але, нажаль, ця

інформація є міжсистемно несумісною.

Проміжні мови. Несумісність інформації, якою оперують різномані-

тні автоматизовані підсистеми, порушує програмну єдність САПР в ціло-

му, не дозволяє реалізувати принципи розвитку та блочності. Тому для об-

міну даними

між системами (поряд з обов’язковим використанням внутрі-

шніх мов) необхідно мати певну уніфіковану мову.

З метою забезпечення передачі інформації між інваріантними до

об’єкта проектування підсистемами САПР останні доповнюються проміж-

ними мовами та мовними процесорами. Тут мовні процесори (перед- та

постпроцесори) використовують відповідно для перетворення інформації з

проміжної мови на

внутрішню (див. блок 6 рис.4.11) та з внутрішньої мо-

ви на проміжну (блок 7). Тоді стає ясно, що коли дві системи можуть

сприймати інформацію від однієї проміжної мови, то ці системи є суміс-

ними. Загальна схема передачі даних між двома підсистемами САПР пода-

на на рис.4.12.

Проміжні мови призначені для обміну даними між підсистема-

ми САПР, а мовні процесори – для читання інформації з викори-

станням граматики однієї мови та запису цієї інформації відпо-

відно до граматики іншої.

Внутрішня

мова

підсистеми 1

Внутрішня

мова

підсистеми 2

Постпроцесор

підсистеми 1

Передпроцесор

підсистеми 1

Проміжна мова

Передпроцесор

підсистеми 2

Постпроцесор

підсистеми 2

Підсистема 1

исунок 4.12 – Забезпечення програмної сумісності підсистем САПР

а допомогою проміжної мови:

– передача даних з підсистеми 1 до підсистеми 2;

– передача даних з підсистеми 2 до підсистеми 1

Підсистема 2

194

При використанні комп’ютерних технологій інформацію, що подана

відмінними внутрішніми або проміжними мовами, записують у файли, які

мають суворо призначене розширення. Саме за цим розширенням здійсню-

ється розпізнавання тієї чи іншої мови. При цьому на практиці найчасті-

ше вживають не терміни “внутрішня” або “проміжна” мови, а поняття

формату збереження даних. Позначення

вказаного формату виконують за

вказаним вище розширенням. Так, наприклад, найбільш розповсюдженою

проміжною мовою систем інженерної графіки є проміжна мова системи

AutoCAD. Відповідні файли креслень у даному випадку мають розширення

DXF. При посиланні на ці файли кажуть, що інформацію подано в DXF-

форматі.

Розглянемо приклад будови відрізка прямої на площині, який пови-

нен

проходити між точками з координатами =10.00, =20.00 та

=100.00, =200.00. Скористаємося для цього SF-форматом проміжної

мови системи КОМПАС:

line (10.00, 20.00, 100.00, 200.00); .

Як бачимо, синтаксична структура процедури будови наданого гра-

фічного примітиву достатньо проста і дозволяє проектувальнику (при не-

обхідності) виконати контроль даних, що подані на проміжній мові. Вод-

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

розміщення окремих лексичних одиниць мови в окремих рядках. Тоді сто-

совно KSF-формату системи КОМПАС розглянута

вище процедура будови

відрізка приймає вигляд:

line

10.00

20.00

100.00

200.00 .

В останньому випадку суттєво зменшується кількість операцій син-

таксичного контролю – в тексті тепер відсутні дужки, коми, інші елементи-

відокремлювачі. Це означає, що читання даних і їх запис у файли приско-

рюється.

В загальному випадку відрізок прямої, як і інші графічні примітиви,

195

може мати атрибути: товщина (тип), колір, шар виведення тощо. Тоді про-

міжна мова може мати структуру “маркер – значення”. Прикладом викори-

стання такої структури є DXF-формат системи AutoCAD:

line

10.00

20.00

100.00

200.00 .

Тут маркер 0 позначає початок нового об’єкта, а маркери

10,20,11,21 – відповідно такі атрибути, як координата

, координата ,

координата

, координата .

У цілому з розглянутого ясно, що неважко розробити мовний проце-

сор для перетворення інформації з однієї проміжної мови на іншу. При

цьому фірми-розробники ПЗ постачають свої системи мовними процесо-

рами для імпорту-експорту даних для достатньо широкого кола проміжних

мов, тобто форматів запису інформації. Наприклад, система SolidWorks до-

зволяє здійснювати

обмін даними в форматах IGES, DXF, DWG, SAT, STL,

STEP, VDAFS, VRML, Parasolid тощо. Повернемось до розгляду рис.3.55,

де бачимо, що імпорт даних у систему КОМПАС здійснюється в форматах

KSF, DXF, DWG, IGES, SAT тощо. Те саме можна навести щодо інших

графічних комплексів, електронних таблиць, текстових процесорів, СКБД.

Це розширює можливості використання цих систем при взаємодії з дани-

ми, отриманими в інших програмних комплексах

Безумовно, що спеціалізовані програмні комплекси САПР ДВЗ, які

слід віднести до розрахункового блока САПР, теж повинні оперувати пев-

ною внутрішньою мовою. Це означає, що для перетворення інформації з

вхідної мови системи на внутрішню та з внутрішньої на вихідну теж здійс-

нюється за допомогою мовних процесорів. Тоді загальна схема інформа-

ційних

зв’язків розрахункового блока САПР відповідатиме схемі рис.4.13.

196

Користувач

Початкові дані

вхідною мовою

Команди мовою

керування

Дані мовою

супроводу

Повідомлення мовою

діагностичних

помилок

Результати

вихідною мовою

Інформація

проміжною мовою

Конвертор 2

Конвертор 1

Мовний постпроцесор

Розрахунковий

блок САПР

(процесор)

Дані

внутрішньою

мовою

Мовний передпроцесор

ЕОМ

исунок 4.13 – Загальна схема інформаційних зв’язків

озрахункового блока САПР

За допомогою проміжних мов стає можливим підключення різнома-

нітних інваріантних підсистем до спеціалізованих розрахункових блоків

САПР. Для цього використовують спеціально розроблені програми, які на-

зивають конверторами. Конвертори здійснюють перетворення даних з

внутрішньої мови певної спеціалізованої підсистеми на проміжну мову ін-

варіантної підсистеми (див. блок 5 на рис.4.13) або в

протилежному на-

прямку (блок 6).

На основі використання проміжних мов поєднаємо між собою схеми,

що подані на рис.4.11 та рис.4.13. У такому випадку будемо мати єдиний

програмний комплекс, що складається зі спеціалізованої підсистеми прое-

ктування та графічної підсистеми обслуговування процесу проектування.

Ефект використання внутрішніх і проміжних мов в САПР ДВЗ.

При

розгляді цього питання можна виділити три складові. Розглянемо їх.

Перша складова. Будемо вважати, що в певній САПР, наприклад,

працюють функціональні підсистеми АСК ДВЗ та АСКВД ДВЗ. На даний

197

момент завданням першої підсис-

теми є автоматичний синтез кре-

слення колеса водяного насоса, а

другої – генерація графіків екс-

периментально отриманої харак-

теристики двигуна. Вказані за-

вдання будуть виконуватись від-

повідно до схеми рис.4.14.

З цього рисунка добре вид-

но, що при залученні до САПР

довільного спеціалізованого бло-

ку проектування виникає потреба

в розробці тільки додаткового

конвертора, який буде здійсню-

вати передачу даних у вибрану

графічну систему (на рис.4.14 –

це конвертори А і Б). При цьому

достатньо складна частина сис-

теми, якою є підсистема машин-

ної графіки, залишається незмін-

ною.

Друга складова. В процесі

синтезу, аналізу та оптимізації конструкції СТС відповідно до

принципу

ітераційності виникає задача багаторазового використання тих чи інших

блоків підсистеми проектування.

Підсистема Б

обробки

експерименталь-

них даних

Внутрішня

мова

підсистеми А

Внутрішня

мова

підсистеми Б

Конвертор А

Конвертор Б

Проміжна мова графічної системи

Мовний передпроцесор графічної системи

Внутрішня мова графічної системи

Креслення

колеса

ВН

Графіки дослідних

характеристик

двигуна

исунок 4.14 – Схема передачі даних з

функціональних підсистем САПР ДВЗ

до інваріантної графічної системи

Підсистема А

синтезу

геометрії

колеса ВН

Безумовно, що для ефективної їх роботи необхідно мати єдине ма-

шинне уявлення (внутрішню мову) моделі об’єкта проектування. Схема

відповідного лінгвістичного забезпечення САПР подана на рис 4.15.

У даному випадку прямі інформаційні зв’язки між блоками синтезу,

аналізу й

оптимізації конструкції відсутні, що дозволяє здійснювати їх роз-

робку як одноетапних САПР, а в перспективі – забезпечити необхідну тех-

нологію проектування і розвиток системи в цілому. При цьому кількість

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

тю визначається прийнятою схемою методичного забезпечення цільового

об’єкта проектування.

198

нутрішня мова

Мови супроводу

і керування

Мови супроводу

і керування

хідна мова

Передпроцесор

Параметри

та показники

об’єкта проектування

Геометрична

модель об’єкта

проектування

Блоки син-

тезу

Постпроцесор

ихідна мова

Блоки

аналізу

Блоки

оптимізації

Конвертор 2D Конвертор 3D

роміжна мова графічної системи

Рисунок 4.15 – Схема лінгвістичного забезпечення

підсистеми проектування

Третя складова. Фірма-виробник програмного забезпечення створи-

ла більш удосконалену систему машинної графіки. Найчастіше в такому

випадку словник проміжної мови буде розширено. Але важливо, що грама-

тика цієї мови залишається незмінною. Такий підхід дозволяє використо-

вувати нову графічну підсистему сумісно з усіма іншими підсистемами ін-

тегрованої САПР

без будь-яких змін в останніх.

З розглянутого можна зробити наступний висновок.

Відповідно до теорії лінгвістичного забезпечення САПР взаємо-

дія користувача з системою та міжпрограмний обмін даними

повинен здійснюватись з використанням вхідних, вихідних мов,

мов керування і супроводу, внутрішніх і проміжних мов. При

цьому зміна розрахункового блока, графічної чи іншої підсисте-

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

або її модернізація не

викликають перебудови інших блоків.

Таким чином, маємо лінгвістичне забезпечення, за допомогою якого

система легко розширяється для розв’язання нового кола задач.

199