Варіанти управління даними в мережах сапр

При мережевій організації САПР інформаційне забезпечення може бути реалізоване по одному з наступних варіантів:

1) FS - файловий сервер;

2) RDA - доступ до видалених даних;

3) DBS - сервер баз даних;

4) AS - сервер додатків.

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

Інтерфейс

Додатки

СУБД

БД

DBS RDA FS

Рис.16.1 Варіанти двохланкових схем розподілених обчислень

Кожен варіант має свою область застосування.

Варіант файл-сервера характерний для локальних мереж на персональних комп'ютерах з невеликим числом користувачів. Унаслідок інтенсивного трафіку і труднощів із захистом інформації ця структура для більшості АС малоефективна. Тому переважно мати СУБД у вузлі сервера. Варіант RDA - це модель видаленого вузла. У ній зменшений трафік в порівнянні з FS, уніфікований інтерфейс з СУБД на основі мови SQL. Клієнтів в FS і RDA іноді іменують «товстими» клієнтами, оскільки в них зосереджені засоби виконання додатків.

Подальший перехід до системи розподілених обчислень приводить до переміщення прикладного ПО або його частини на спеціальний сервер або сервер БД, тобто реалізуються двох- і трьохланкові схеми.

DBS - двохланкова структура дистанційного керування, заснована на розділенні прикладних процедур на дві частини: індивідуальні для кожного користувача і загальні для багатьох завдань. У цій структурі під додатком розуміють сукупність саме загальних процедур. Ця сукупність зазвичай представляється на процедурних розширеннях SQL і зберігається в спеціальному словнику БД. У альтернативних варіантах (наприклад, в RDA) всі прикладні процедури включаються в прикладні програми і, отже, при необхідності їх зміни доводиться модифікувати практично все прикладне ПО. Виділення таких процедур в окремий додаток полегшує їх модифікацію. Крім того, в DBS знижується трафік, оскільки обміни по мережі відбуваються не для кожної операції з БД, а для кожної транзакції, що складається з декількох операцій.

Варіант AS реалізується за трьохланковою схемою, в якій для додатків використовуються вузли, відокремлені від термінального (локального) вузла і від сервера БД, тобто одночасно використовуються моделі DBS і RDA.

Крім проблеми розподілу серверних функцій між вузлами мережі, є проблема розділення цих функцій між багатьма користувачами АС. Ця проблема вирішується або за схемою «один – до - одного», або за багатопотоковою схемою. У першій з них для кожного активного користувача створюється своя копія СУБД. У другій СУБД повинна бути реентерабельною програмою, що обслуговує одночасно багато користувачів.

Розподілені бази даних

У крупних САПР, побудованих на основі корпоративних мереж, не завжди вдається організувати централізоване розміщення всіх баз даних і СУБД на одному вузлі мережі. В цьому випадку створюють розподілені БД (РБД) [1].

При побудові РБД доводиться вирішувати ряд складних проблем, пов'язаних з мінімізацією трафіку, забезпеченням інтероперабельності обробки даних і цілісності даних.

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

Інтероперабельність виражає здатність взаємодії програм, що працюють в гетерогенних мережах (у різних операційних середовищах або з різними СУБД). Інтероперабельність забезпечується або за допомогою програм-шлюзів (конверторів) (для кожної пари тих, що взаємодіють) середовищ, або за допомогою єдиної уніфікованої мови взаємодії. Такою мовою для доступу до БД є мова SQL, інтероперабельність на його основі має місце в системі ODBC, приклад реалізації якої показаний на рис.16.2 У прикладі СУБД FoxPro знаходиться в локальному вузлі, а СУБД Ingres і Informix - у видалених вузлах. Прикладна програма має ODBC-інтерфейс, не залежний від особливостей різних СУБД. Менеджер драйверів реалізує на базі уніфікованої мови SQL всі нюанси доступу до БД, загальні для різних СУБД. Драйвер конкретної СУБД перетворить інваріантні до СУБД запити у форму, прийняту в даній СУБД.

Рис.16.2 Структура ODBC

Забезпечення цілісності в РБД набагато складніше, ніж в одновузлових БД. Розрізняють два підходи до побудови РБД:

1) тиражування (реплікація), при якому на декількох серверах (вузлах) мережі розташовані копії БД;

2) повномасштабна розподіленість, при якій різні частини БД знаходяться на різних серверах мережі (класична розподіленість).

Застосовують два способи тиражування.

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

Надійність підвищується при використанні способу голосування. Тут зміни посилаються не в один первинний, а в деякі N серверів. При цьому будь-який запит на читання прямує до деяких М серверів, причому N + М > К, де К - загальне число серверів. Приймається остання за часом оновлення версія відповіді.

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

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

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

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

Складніше вирішувати проблеми розподіленого управління, що потрібний в РСУБД без тиражування. Одним з поширених протоколів розподіленого управління є протокол двофазної фіксації транзакцій. На першій фазі ініціатор транзакції (координатор) розсилає учасникам виконання транзакції сповіщення про блокування. У відповідь вузли повідомляють про свою готовність або неготовність. На другій фазі координатор повідомляє або про «глобальну фіксацію», тобто про виконання транзакції, або про відкіт транзакції. Неприємності можливі при збоях, які можуть залишити деякий вузол в заблокованому стані, при якому він не може ні виконувати транзакцію, ні відміняти її в односторонньому порядку.

Розвитком РСУБД є розподілені сховища даних, що використовують єдину логічну модель з безліччю фізичних місць розташування. Дані логічно розділяються на домени (наприклад, всі записи, що відносяться до конкретного регіону, до всіх даних клієнтів з одного місця і т.п.) і розподіляються без дубльованих записів по різних крапках (locations). Причин для використання такого підходу множина - починаючи від створення фізичних зон безпеки даних і закінчуючи аналітичними операціями, що ґрунтуються на часових зонах.

Лекція 18-19 Характеристика розповсюджених САПР ЗОТ

План лекції

1. САПР візуального моделювання і проектування алгоритмів та систем обробки цифрових сигналів

2. Програма ORCAD Capture для створення принципових електричних схем

3. Вибірання інструментальних засобів для проектування друкарських плат

САПР візуального моделювання і проектування алгоритмів та систем обробки цифрових сигналів

Засоби "візуального" проектування і моделювання алгоритмів і систем цифрової обробки сигналів (ЦОС) займають особливе місце серед інструментальних засобів розробників телекомунікаційного і іншого електронного устаткування на базі процесорів ЦОС. Дані за­соби не тільки автоматизують процес проектування, позбавляючи розробника рутинної праці і скорочуючи терміни проектування, але і дозволяють фахівцям прикладних областей науки і техніки, які не знайомі з процесорами ЦОС і не володіють програмуванням, засто­совувати для вирішення своїх завдань досягнення технологій циф- рової обробки сигналів.

У даний час існує декілька пакетів "візуального" проектування і моделювання алгоритмів та систем ЦОС, які функціонують на різ- них апаратних платформах і відрізняються між собою функціональ­ними можливостями, швидкодією і вартістю. Зокрема засоби “візу­ального” проектування і моделювання алгоритмів ЦОС Hypersignal RIDE і Hypersignal Block Diagram.

Програма HyperSignal Block Diagram/RIDE (Real-time Integrated Development - можливість підключення апаратури для опрацювання сигналів у реальному часі) призначена для моделювання аналогових і цифрових пристроїв, заданих функціональними схемами. До складу Hypersignal входить декілька сотень тематично згру­пованих функцій-блоків. Серед них: блоки генераторів сигналів, блоки арифметичних функцій, блоки матричних і векторних опера­цій, блоки функцій ЦОС, блоки файлових операцій, блоки візуалі­зації сигналів та інші. У склад САПР Hypersignal також входять блоки управління: клавіатури, перемикачі, лінійні і стрілкові інди­катори, тощо. Наявність цих функціональних блоків дозволяє ство­рювати інтуїтивний для користувача інтерфейс системи, що розроб­ляється, спільно з розробкою алгоритму її функціонування. Крім то­го разом із САПР Hypersignal поставляються спеціалізовані бібліо­теки функцій для обробки мови (Advanced Speech Library), бібліоте­ка комунікаційних функцій (Advanced Transmission Library) і бібліо­тека функцій для обробки зображень (Image Processing Library).

У разі відсутності необхідних функцій, користувач може створи­ти їх самостійно за допомогою конструктора блоків (Block Wizard), що входить в склад САПР Hypersignal. Все, що при цьому необхід­но зробити - написати функцію блоку на мові С, використовуючи стандартні засоби, і в інтерактивному режимі описати новий блок, задаючи його конфігурацію і описуючи його параметри.

САПР Hypersignal підтримує ієрархічне проектування, при якому блоки можуть об'єднуватися і входити у вигляді одного блоку в блок-схему більш високого рівня ієрархії, що дозволяє не тільки структурувати складний проект, але і розбивати його на частини для реалізації різними виконавцями.

У середовищі Hypersignal алгоритм створюється у вигляді блок­схеми на екрані ПК в інтерактивному режимі із стандартних блоків, при цьому встановлювані міжблочні зв'язки відображатимуть пото­ки даних і шляхи проходження сигналів. Настройка параметрів ал­горитму здійснюється шляхом вибору відповідних блоків і установ­кою потрібних параметрів за допомогою системи меню, а модифі­кація алгоритму здійснюється шляхом зміни його блок-схеми і па­раметрів блоків.

При запуску введеного алгоритму Hypersignal RIDE створює ви­конавчий код відповідного алгоритму. Далі цей код автоматично за­вантажується в середовище процесора ЦОС апаратних засобів і пе­редається виконання. При необхідності (особливо на етапі відладки алгоритму) відображення результатів обробки сигналів може здійс­нюватися на екрані ПК в режимі реального часу. На рис.18.1преставлений приклад інтерфейсу системи Hypersignal Block Diagram/RIDE. У САПР Hypersignal Block Diagram існує велика різноманітність готових прикладів, вивчення яких дозволяє швидко освоїти систему і навчитися максимально повно використовувати її можливості. Як показано вище, процес моделювання в середовищі САПР Hypersignal інтуїтивно зрозумілий і не є трудомістким навіть для дуже складних пристроїв і систем. Застосування САПР Block Diagram дозволило відмовитися від безпосереднього програмуван­ня, що скоротило час створення моделей у десятки разів і дозволило легко імплементувати даний алгоритм в системі ЦОС на цифровому сигнальному процесорі.

Рис. 18.1. Інтерфейс система Hypersignal Block Diagram/ride

Програма ORCAD Capture для створення принципових електричних схем

Програма ORCAD Capture призначена для створення проекту, частина якого може бути задана у вигляді принципової електричної схеми, а інша частина може бути описана на мові високого рівня VHDL. Крім того, з оболонки ORCAD Capture запускаються програми моделювання аналогових, цифрових і змішаних аналого­цифрових пристроїв Pspiсe і параметричній оптимізації Pspiсe Optimizer. У програмі ORCAD Capture проекти поділяються на де­кілька типів.

Перелік програмних модулів, що входять до складу ORCAD 9.2: ORCAD Capture - графічний редактор схем;

ORCAD Capture CIS (Component Information System) - графічний редактор схем, доповнений засобом ведення баз даних компонентів; при цьому зареєстровані користувачі отримують через інтернет до­ступ до каталогу компонентів, що містить більше 200 тис. наймену­вань;

Pspice Schematics - графічний редактор схем, запозичений з паке­ту Designlab;

ORCAD Pspice A/d - програма моделювання аналогових і зміша­них аналого-цифрових пристроїв, дані в яку передаються як з Pspice Schematics, так і з ORCAD Capture;

ORCAD Pspice Optimizer - програма параметричної оптимізації;

ORCAD Layout - графічний редактор друкованих плат (ДП);

ORCAD Layout Plus - програма ORCAD Layout, доповнена безсі­тковим автотрасувальником Smartroute, що використовує методи оптимізації нейронних мереж (використовується також в системах Protel 99 SE і P-CAD 2000);

ORCAD Layout Engineer's Edition - програма перегляду друкова­них плат, створених за допомогою Layout або Layout Plus, засіб за­гальної розстановки компонентів на платі і прокладки найбільш критичних ланцюгів, що виконуються інженером-схемотехником перед видачею завдання на проектування друкованої плати конс­труктору;

ORCAD Gerbtool - програма створення і доопрацювання управ­ляючих файлів для фотоплотерів (розробка фірми WISE Software Solutions спеціально для ORCAD, аналог програми Сам350);

Visual CADD - графічний редактор фірми Numera Software (спрощений аналог AUTOCAD).

При створенні проекту відповідно до його типу автоматично за­вантажуються необхідні бібліотеки компонентів, при цьому для всіх спеціалізованих проектів можлива передача інформації в програму ORCAD Layout для створення друкованих плат. На рис. 10.2 пока­заний взаємозв'язок ORCAD Capture з іншими програмами. При створенні принципових схем проекту необхідна інформація відшу­кується кується у вбудованій базі даних, яка поставляється разом з систе­мою і поповнюється користувачами. Причому за наявності опції Component Information Systems (CIS) офіційні користувачі дістають отримують через інтернет до розширеної бази даних, що містить зведення приблизно об 200 тис. компонентів різних фірм (приведені їх символи і корпуси). На рис. 18.3 зображений екран програми ORCAD Capture 9.2. У його верхній частині розташовано меню ко­манд, а нижче - панель інструментів.

Рис. 18.2. Взаємозв'язок ORCAD Capture з іншими програмами

Рис.18.3 Екран програми ORCAD Capture

Меню команд і панель інструментів ORCAD Capture залежить від вибраного режиму роботи та типу поточного проекту. Melte­doicep npoexmie розташований в лівій частині екрану програми Capture. У режимі File розгортається плоска файлова структура про­екту, в режимі Hierarchy - його ієрархічна структура. Файлова стру­ктура проекту містить ряд розділів:

Design Resource - опис проекту (файл проекту *.dsn, окремі сто­рінки схеми, перелік компонентів Design Cache, VHDL-файли, пе­релік використовуваних бібліотек компонентів *.olb);

Outputs - результати проектування;

Pspice Resource - інформація для моделювання за допомогою Pspice (Include Files, Model Library, Simulation Profiles, Stimulus Files) і ін.

На рис. 18.4 показано вікно редактора сторінки принципової схеми, на якій розташовані

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

Рис. 10.4. Вікно редактора сторінки схеми

Texcmoeuii pedaxmop дозволяє створювати і переглядати VHDL­файли і будь-які інші текстові файли. На рис. 18.5. показаний фраг­мент VHDL-файла, ключові слова в якому і коментарі для наочності виділяються різними кольорами, що задаються в розділі Preferences меню Options. Завантаження в редактор VHDL-файла виконується після подвійного клацання лівої клавіші миші при розташуванні ку­рсору на імені файлу у менеджері проектів, текстові файли інших типів відкриваються звичайним способом по команді File>open>text File.

На рис. 18.5. показаний фраг­мент VHDL-файла,

У нижній частині екрану ORCAD Capture розташований plidox cmanie , на якому відображається ім'я вибраного інструменту або меню, ім'я поточного стану програми (у лівому полі), кількість виб­раних об'єктів (у середньому полі), масштаб зображення і поточні координати курсору (у правому полі). Кожен об'єкт принципової схеми має набір властивостей (Properties), що повністю визначають його характеристики.

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

Основним з ключових питань в організації інтегральної системи автоматизованого проектування і виробництва електронно-обчислювальної техніки є вибір EDA -інструментів. Основними чинниками при виборі базового eda-інструменту є:

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

2. Наявність інтерфейсу між вибираним інструментальним засобом і використовуваним на підприємстві.

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

4. Використання вже наявних локальних мереж.

5.Наявність інтерфейсу з EDA -інструментамі, використовуваними іншими зарубіжними науковими центрами, з якими є спільні проекти.

6.Вартість вибираного інструменту. Наличие интерфейса с EDA-инструментами,

1.Cистемы автоматизированного проектирования: Учеб. пособие для втузов: В 9 кн./

Под ред. Норенкова И.П. — М.: Высш. шк., 1986.

2. Системы автоматизированного проектирования. Ка.1-9 (Серия учебных пособий под ред. Норенкова И.П.) М., Высш.шк., 1986г.

3. Петренко А.И., Семенков О.И. Основы построения систем автоматизированного проектирования. – Киев, Высш.шк. 1984 г.

4. Норенков И.Н. Введение в автоматизированное проектирование технических устройств и систем. – М., Высш.шк., 1985 г.

5. Корячко В.П., Курейчик В.М., Норенков И.Н. Теоретические основы САПР. – М., Энергоиздат, 1987 г.