Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Загальна характеристика ОСРЧ

Ринок ОС РЧ сьогодні стабілізувався і достатньо жорстко поділений на галузеві і регіональні сектори - до 80 % продажів припадає на 5-6 систем-лідерів. За різними дослідженнями, шістка виглядає так: pSOS+, VxWorks, VRTX, OS9, LynxOS, Windows NT із розширенням реального часу.

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

І, нарешті, операційна система реального часу - усе-таки не самоціль. Кінцева ціль застосування ОС РЧ - скорочення термінів розробки сучасних апаратно-програмних комплексів реального часу.

На сьогоднішній день існують чотири класи операційних систем реального часу (ОС РЧ) (рис.1). </big>

<big>Ядра реального часу</big> <big>Виконавчі системи реального часу </big> <big>UNIX’ и реального часу</big> <big>Windows NT з розширенням реального часу</big>
Переваги:- масштабованість, - модульність, - розвинутий інструментарій. Переваги:- компактність, - реактивність. Область застосування:компактні вмонтовані системи з швидкими часами реакції. Переваги:- UNIX- сумісність додатків, - розвинутий інструментарій. Область застосування:великі системи реального часу. Переваги:- загальнопризнана ОС, - можливості Win32. Область застосування:від невеликих вмонтованих систем до великих систем реального часу.
<big>OS9, QNX</big> <big>VxWorks, pSOS, VRTX, PDOS, RTKernel</big> <big>LynxOS</big> <big>VenturCom, LP Elektronik, Radisys, Imagination</big>

<big>Рис.1 Класи систем реального часу

Ядра реального часу. У цей клас входять системи з монолітним ядром, де й міститься реалізація всіх механізмів реального часу. Історично системи даного типу були добре спроектовані. Розроблювачі цих систем - на відміну від творців систем інших класів, що з'являлися як тимчасові компроміси і потім нарощувались завдяки першим удалим реалізаціям (виконавчі системи реального часу і UNIX реального часу) - мали час для розробки систем саме реального часу і не були обмежені у виборі засобів (наприклад, фірма Microware для підготовки до випуску першого варіанта OS-9 мала у своєму розпорядженні три роки). Системи цього класу, як правило, модульні, добре структуровані, мають розвинений набір специфічних механізмів реального часу, компактні і прогнозовані. Самі популярні системи: OS-9, QNX. Одна з особливостей продуктів цього класу - високий ступінь масштабованості. На їхній базі можна побудувати як компактні системи реального часу, так і великі системи серверного класу. Як правило, їх ядра реального часу мають два типи систем розробки - кросову і резидентну.

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

UNIX подібні системи реального часу. Історично системи реального часу створювалися в епоху розквіту ОС UNIX, тому багато із них містять ті або інші запозичення з цієї гарної концепції операційної системи (інтерфейс користувача, концепція процесів і т.д.). Частина розроблювачів ОС РВ спробувала просто переписати ядро UNIX, зберігши при цьому інтерфейс процесів користувача із системою, наскільки це було можливо. Реалізація ідеї не викликала утруднень, оскільки не було перешкод у доступі до вихідних текстів ядра, а результат виявився чудовим. Одержали і реальний час, і відразу весь набір додатків користувача - компілятори, пакети, різноманітні інструментальні системи. У цьому смислі розроблювачам систем перших двох класів довелося потрудитися при створенні не тільки ядра реального часу, але і просунутих систем розробки. Проте сімейство Unix реального часу не позбавлено хиб: системи реального часу утворюються достатньо великими і менше реактивними, ніж системи перших двох класів. Найбільшим попитом користується операційна система реального часу Lynx OS.

Розширення реального часу для NT. Отже, чи варто тривожитися виробникам традиційних операційних систем реального часу в зв'язку з появою на ринку розширень реального часу для Windows NT?

Щоб відповісти на це запитання, недостатньо одного аналізу тенденцій розвитку операційних систем реального часу і програмних технологій. Необхідний і аналіз тенденцій нових апаратних технологій на ринку промислової автоматизації. І не випадково виробники розширень Windows NT реального часу будують моделі розвитку ринку промислової автоматизації, із яких випливає, що всі промислові контролери двадцять першого сторіччя будуть містити процесори Intel [2]. Звісно ж, це дуже малоймовірно (у першу чергу, через те, що низка Wintel не спозиційована в цілому на ринок систем реального часу), і в цьому смислі більш об'єктивним є аналіз спеціалістів, для котрих ОС РЧ - тільки один із компонентів побудови апаратно-програмних комплексів [3]. Проте не можна забувати і про те, що потужність сучасних вмонтованих Intel-контролерів, наприклад на платформі VME або CompactPCI, постійно зростає, а ціна знижується, що вже дозволяє застосовувати Windows NT.

З іншого боку, поява нових програмних технологій, таких, як OPC (OLE-For Рrocess Control), говорить про тенденції розподілу функцій системи реального часу по рівнях. Значно більш ємний ринок для них - домашні приставки інтерактивного телебачення, щільникові телефони нового покоління і т.п. Словом, як завжди, ринок повний суперечливих тенденцій.

Системи перших двох класів із появою на ринку Windows NT не випробують ніякого тиску, оскільки область їх застосування - компактні, умонтовані додатки жорсткого реального часу на контролерах різноманітної архітектури (серед котрих і Intel). Малоймовірним є скільки-небудь широка заміна цих систем на Windows NT. На це є декілька причин:

1. невелика кількість архітектур, підтриманих Windows NT;

2. неможливість побудови компактної системи (контролер повинний містити електронний диск у Flash-пам'яті обсягом не менше 10 Мбайт і оперативну пам'ять не менше 16 Мбайт);

3. у додатках жорсткого реального часу може використовуватися тільки один комплект розширень - додаткове ядро реального часу;

4. бідний набір механізмів міжзадачної комунікації.

Інакша справа з великими системами реального часу. Традиційно цю нішу займали клони UNIX реального часу і масштабовані системи перших двох класів. Ці системи звичайно використовуються, коли немає жорстких вимог до реального часу, або коли система містить тільки окремі критичні ділянки. Часто UNIX реального часу застосовується в тих додатках, де система потребує розвинених сітьових можливостей або можливостей архівування даних. У цьому смислі історії появи клонів UNIX реального часу і розширень реального часу для Windows NT дивовижно схожі. Основна ідея створення UNIX РВ полягала в тому, щоб перенести на рівень керуючих систем найбільш потужну на той момент програмну технологію - із розвиненим програмним інтерфейсом (POSIX), широким набором різноманітних додатків і великої кількості кваліфікованих спеціалістів. Все це слово в слово можна повторити про теперішню ситуацію, замінивши UNIX на NT, а POSIX на WIN32 API. У системі UNIX, так само як і в NT, споконвічно закладені елементи реального часу, що послужило додатковим імпульсом для їхнього впровадження у світ реального часу.

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

Розширення реального часу Windows NT мають ті ж слабкі сторони, що і UNIX РВ: неможливість побудови компактних систем і множина недоліків при роботі в реальному часі.

Подібність історії і проблем, а також технічні аналогії дозволяють із високим ступенем можливості припустити, що на ринку ОС РЧ розширення Winows NT будуть боротися за нішу, що вже займають зараз UNIX РЧ - нішу великих систем з обмеженими вимогами до реального часу.

 

Лекція 3. Сучасні архітектури систем ЧПУ типу PCNC

 

 

У середовищі розробників і виробників систем ЧПУ остаточно склалося розуміння того, що сучасні системи керування повинні в максимальному ступені використовувати досягнення комп'ютерної технології [1, 2]. У системах ЧПУ нового покоління прийнято виділяти системну платформу PC (Personal Computer) і прикладну компоненту NC (Numerical Control, тобто ЧПУ). Звідси випливає і загальне позначення класу PCNC [3]. Системна платформа робить свої послуги модулям прикладної компоненти через прикладний інтерфейс API (Application Program Interface) кожного модуля, причому API приховує механізм реалізації будь-яких послуг. У системі PCNC підтримується мобільність прикладних модулів (тобто їх переносимість на інші системні платформи); комунікабельність модулів (тобто їхня здатність до взаємодії через єдине комунікаційне середовище системної платформи); масштабованість системи в цілому (тобто можливість змінювати, при необхідності, як функціональність прикладної компоненти, так і обчислювальні можливості системної компоненти).

Розвиток даного напрямку підтримується європейськими програмами (наприклад, OSACA, Open System Architecture for Controls within Automation systems, див. [4]).

 

1.Структура прикладної компоненти PCNC

 

Для прикладної компоненти можна виділити три рівні декомпозиції. Перший рівень полягає у виділенні "задач керування" (task areas) [5]. У числі подібних задач: геометрична (motion control), логічна (logic control), термінальна (human machine control) і, можливо, інші. Другий рівень декомпозиції полягає у виділенні модулів у складі задач керування, причому кожний окремий модуль відповідає фазі вирішення задачі керування. Так, до складу геометричної задачі керування входять: диспетчер режимів (manager); інтерпретатор (ISO-процесор [6]); інтерполятор; модуль керування слідкуючими приводами (axes control). Частина таких модулів має власний прикладний інтерфейс API (рис.1), інші ж об'єднуються в групи з метою побудови загального інтерфейсу API.

 

 
 

Рисунок 1. Задачі і модулі в архітектурі PCNC

 

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

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

 

2. Поняття про прикладний інтерфейс API модулів прикладної компоненти

 

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

 
 

Рисунок 2.
Взаємодія модулів за допомогою прикладного інтерфейсу API
: Cco (Client Communication Object) - об'єкти модуля-клієнта
; Sco (Server Communication Object) - об'єкти модуля-серверу
; Cco1, Cco2, Sco1, Sco2 - об'єкти класу "об’єкт-перемінна"
; Cco3, Sco3 - об'єкти класу "об'єкт-процес"
; v(variable) - перемінна; p(process) - процес

З такої структури API випливають такі можливості:

· усі модулі (і групи модулів) можуть взаємодіяти між собою за допомогою власних API через єдине комунікаційне середовище, що являє собою по суті віртуальну шину [7];

· між будь-якою парою модулів (включаючи, можливо, групу модулів) можуть виникати клієнт-серверні відношення, причому, модуль (або група) може бути як клієнтом, так і сервером

· використовуючи запити типу SEND і RECEIVE, модулі (або група) можуть посилати нові значення змінних іншим модулям (або групам), читати значення змінних з інших модулів (або груп);

· одні модулі (або групи) можуть управляти переходами інших модулів (або груп) у нові стани (наприклад, скидання, готовності, запуску, роботи, виходу з роботи, помилки й ін.).

· всі об'єкти в складі API мають імена, структура яких: <абревіатура модуля, групи або задачі><ім'я змінної або процесу>.

 

3. Структура системної платформи і її комунікаційного середовища

 
 

У системну платформу PCNC входять: апаратна частина, операційна система і засоби підтримки міжмодульних комунікацій.

 
 

Рисунок 3.
Однокомп'ютерний (а) і двокомп’ютерний (б) архітектурні варіанти PCNC

 

Стандартну апаратуру персонального комп'ютера розширюють за рахунок плати вмонтованого програмованого контролера, а також інтерфейсних плат контролерів слідкуючих приводів і електроавтоматики. Системи PCNC будують на основі одного або двох комп'ютерів (рис.3) [8]. В другому випадку комп'ютери можуть бути однаковими або різними; причому один із них "звернений" до оператора (термінал), а інший - до об'єкта керування (машина реального часу). У якості операційної системи для однокомпьютерного варіанта PCNC використовують Windows NT із розширенням реального часу на рівні пристроїв (devices), до яких відносяться контролери вводу-виводу. У двокомпьютерному варіанті PCNC застосовують дві різні операційні системи: Windows NT у терміналі; одну з операційних систем реального часу в машині реального часу (UNIX, VxWorks або ін.).

Структуру комунікаційного середовища PCNC (рис.4) зручно зіставити з класичною багаторівневою моделлю архітектури відкритих систем ISO-OSI [9]. У комунікаційному середовищі прийнято, відповідно до OSACA, виділяти чотири рівні.

· Знизу знаходяться стандартні комунікаційні засоби, що охоплюють фізичний і канальний рівні моделі ISO-OSI. Для двокомпьютерного варіанта подібні засоби можуть бути реалізовані на базі стандартних протоколів Intranet.

Вище іде рівень MTS (Message Transport System, система транспортування повідомлень); цей рівень виконує функції мережевого і транспортного рівнів моделі ISO-OSI. Для двокомпьютерної системи PCNC у рівень MTS може бути вмонтований чотирерівневий стек протоколів TCP/IP. Система транспортування повідомлень MTS підтримує базові транспортні функції (SEND, RECEIVE) для обміну різноманітними повідомленнями між різними парами модулів. MTS приховує від прикладної частини PCNC як стандартні засоби комунікації (такі, як TCP/IP або ін.), так і усі функції операційної системи, у яких вимагається верхня частина комунікаційного середовища. Модулі, розташовані в різних комп'ютерах, взаємодіють за допомогою MTS так, як якби вони знаходилися в одному комп'ютері. MTS використовує протокол із попереднім встановленням з'єднання. Це означає, що два взаємодіючі MTS-користувачі повинні спочатку встановити з'єднання, а вже

 
 

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

Рисунок 4.Зіставлення структур комунікаційного середовища PCNC

і моделі ISO - OSI

 

· Вище розташований рівень ASS (Application Services System, система послуг для прикладних програм); цей рівень відповідає сесійному, представницькому і прикладному рівням моделі ISO-OSI. Система ASS надає послуги (із попереднім встановленням з'єднання) прикладним модулям PCNC у такий спосіб. Якщо модуль вимагає віддаленого зв'язку, то ASS формує повідомлення, що містить отриману від модуля інформацію. Далі визивається послуга рівня MTS для посилки повідомлення. На стороні прийому ASS інтепретує повідомлення і передає його модулю-одержувачу. Перед передачею повідомлення ASS підготовляє дані в такій формі, у якій вимагає приймаюча система. Якщо два модулі (або декілька модулів) мають загальну ASS, то вони не потребувають у MTS для підтримки інтерактивності.

· Четвертий рівень лише умовно відноситься до комунікаційного середовища - це прикладний інтерфейс усіх модулів NC-підсистеми, що мають API. Четвертий рівень реалізований як диспетчер комунікаційних об'єктів COM (Communication Object Manager), що асоційований із кожним модулем, що має API. Диспетчер COM являє собою оболонку, наповнену програмами, призначеними для створення, знищення й активізації так званих "комунікаційних об'єктів".

 

4. Взаємодія модулів прикладної компоненти

 

Зовнішні інтерфейси прикладних модулів являють собою набір комунікаційних об'єктів, що працюють у середовищі диспетчера COM. Набори об’єктів породжуються двома класами (згаданими вище), що формують API (класи "об’єкт-перемінна" і "об'єкт-процес"); а також і двома додатковими класами:

· "об'єктом-подією" для автоматичного повідомлення про зміну значень перемінних при асинхронних транзакціях (сесіях) між клієнтом і сервером;

· "об’єктом-транзакцією" (тільки на стороні клієнта), що містить функції опрацювання даних, одержуваних клієнтом у свої об'єкти класу "об’єкт- перемінна" (вивід на екран, обчислення й ін.).

При такій побудові зовнішніх інтерфейсів вони легко доступні як для клієнта, так і для сервера. Якщо клієнт бажає одержати доступ до інформації сервера (прочитати, записати), то необхідно передбачити комунікаційний об'єкт Cco (Client communication object) на стороні клієнта і цей об'єкт повинен відповідати серверному комунікаційному об'єкту Sco (Server communication object). Повинен бути, принаймні, один Cco, що запитує послуги в Sco. Cco різних прикладних модулів можуть бути одночасно пов'язані з тим самим Sco.

 
 

Наприклад, серверний комунікаційний "об’єкт-перемінна" ScoVariable зберігає дані відповідної серверної перемінної. У кожного клієнта є інший комунікаційний "об’єкт-перемінна" CcoVariable, використовуючи який клієнтський додаток має прямий доступ до серверних даних в ScoVariable і можливість відображення в себе цих даних (рис.5).

Рисунок 5. Приклад доступу клієнтського додатка до даних серверу

 

 
 

Точно так само комунікаційний "об'єкт-процес" ScoProcess на стороні серверу цілком визначає автомат станів серверу з усіма серверними переходами (рис.6). Комунікаційний "об'єкт-процес" CcoProcess на стороні клієнта використовується для керування автоматом стану шляхом виклику передбачених дій (actions).

Рисунок 6.Приклад керування з боку клієнтського додатка переходами між станами серверу

 

Взаємодія клієнта і сервера носить характер синхронної або асинхронної транзакції (рис.7). При посилці синхронного запиту, що запитує Cco очікує відповіді від Sco і залишається заблокованим, поки не надійде підтвердження від запитуваної послуги. Після відправлення асинхронного запиту додаток продовжує свою роботу, а відповідь від серверу надходить або в міру його готовності, або по події. Останнє означає, що клієнт бажає бути сповіщеним сервером при всякій зміні Sco-Variable або ScoPro-cess. У цьому випадку на стороні серверу динамічно (тобто в процесі роботи) створюється "об'єкт-подія" ScoEvent. Його створення ініціюється "об'єктом-подією" CcoEvent, у якому зазначені перемінна, що спостерігається або процес, що спостерігається. Буває так, що під час асинхронної транзакції відповіді серверу повинні якось опрацьовуватися в клієнта. У цих випадках створюється спеціальний додатковий об'єкт - "обєкт-транзакція" CcoTransaction.

 
 

Рисунок 7. Синхронна й асинхронна транзакції

 

Висновок

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

 

 

Лекція 3. Сучасні архітектури систем ЧПУ типу PCNC

 

У середовищі розробників і виробників систем ЧПУ остаточно склалося розуміння того, що сучасні системи керування повинні в максимальному ступені використовувати досягнення комп'ютерної технології [1, 2]. У системах ЧПУ нового покоління прийнято виділяти системну платформу PC (Personal Computer) і прикладну компоненту NC (Numerical Control, тобто ЧПУ). Звідси випливає і загальне позначення класу PCNC [3]. Системна платформа робить свої послуги модулям прикладної компоненти через прикладний інтерфейс API (Application Program Interface) кожного модуля, причому API приховує механізм реалізації будь-яких послуг. У системі PCNC підтримується мобільність прикладних модулів (тобто їх переносимість на інші системні платформи); комунікабельність модулів (тобто їхня здатність до взаємодії через єдине комунікаційне середовище системної платформи); масштабованість системи в цілому (тобто можливість змінювати, при необхідності, як функціональність прикладної компоненти, так і обчислювальні можливості системної компоненти).

Розвиток даного напрямку підтримується європейськими програмами (наприклад, OSACA, Open System Architecture for Controls within Automation systems, див. [4]).

 

1.Структура прикладної компоненти PCNC

Для прикладної компоненти можна виділити три рівні декомпозиції. Перший рівень полягає у виділенні "задач керування" (task areas) [5]. У числі подібних задач: геометрична (motion control), логічна (logic control), термінальна (human machine control) і, можливо, інші. Другий рівень декомпозиції полягає у виділенні модулів у складі задач керування, причому кожний окремий модуль відповідає фазі вирішення задачі керування. Так, до складу геометричної задачі керування входять: диспетчер режимів (manager); інтерпретатор (ISO-процесор [6]); інтерполятор; модуль керування слідкуючими приводами (axes control). Частина таких модулів має власний прикладний інтерфейс API (мал.1), інші ж об'єднуються в групи з метою побудови загального інтерфейсу API. Прикладом подібної групи може послужити "канал ЧПУ" (channel), що об'єднує інтерпретатор і інтерполятор. Виділення каналу особливо корисно в багатоканальних системах ЧПУ, що працюють із декількома керуючими програмами і обслуговують декілька об'єктів-верстатів. Об'єднання модулів у групи знижує навантаження на комунікаційне середовище, проте при цьому зменшується гнучкість системи ЧПУ і її спроможність до реконфігурації.

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

 
 

Рисунок 1. Задачі і модулі в архітектурі PCNC

 

2. Уявлення про прикладний інтерфейс API модулів прикладної компоненти

 
 

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

 

Рисунок 2.
Взаємодія модулів за допомогою прикладного інтерфейсу API
: Cco (Client Communication Object) - об'єкти модуля-клієнта
; Sco (Server Communication Object) - об'єкти модуля-серверу
; Cco1, Cco2, Sco1, Sco2 - об'єкти класу "об’єкт-перемінна"
; Cco3, Sco3 - об'єкти класу "об'єкт-процес"
; v(variable) - перемінна; p(process) - процес

З такої структури API випливають такі можливості:

· усі модулі (і групи модулів) можуть взаємодіяти між собою за допомогою власних API через єдине комунікаційне середовище, що являє собою по суті віртуальну шину [7];

· між будь-якою парою модулів (включаючи, можливо, групу модулів) можуть виникати клієнт-серверні відношення, причому, модуль (або група) може бути як клієнтом, так і сервером

· використовуючи запити типу SEND і RECEIVE, модулі (або група) можуть посилати нові значення змінних іншим модулям (або групам), читати значення змінних з інших модулів (або груп);

· одні модулі (або групи) можуть управляти переходами інших модулів (або груп) у нові стани (наприклад, скидання, готовності, запуску, роботи, виходу з роботи, помилки й ін.).

· всі об'єкти в складі API мають імена, структура яких: <абревіатура модуля, групи або задачі><ім'я змінної або процесу>.

3. Структура системної платформи і її комунікаційного середовища

 
 

У системну платформу PCNC входять: апаратна частина, операційна система і засоби підтримки міжмодульних комунікацій.

 
 

Рисунок 3.
Однокомпьютерний (а) і двокомпьютерний (б) архітектурні варіанти PCNC

 

Стандартну апаратуру персонального комп'ютера розширюють за рахунок плати вмонтованого програмованого контролера, а також інтерфейсних плат контролерів слідкуючих приводів і електроавтоматики. Системи PCNC будують на основі одного або двох комп'ютерів (рис.3) [8]. В другому випадку комп'ютери можуть бути однаковими або різними; причому один із них "звернений" до оператора (термінал), а інший - до об'єкта керування (машина реального часу). У якості операційної системи для однокомпьютерного варіанта PCNC використовують Windows NT із розширенням реального часу на рівні пристроїв (devices), до яких відносяться контролери вводу-виводу. У двокомпьютерному варіанті PCNC застосовують дві різні операційні системи: Windows NT у терміналі; одну з операційних систем реального часу в машині реального часу (UNIX, VxWorks або ін.).

 
 

Рисунок 4.Зіставлення структур комунікаційного середовища PCNC

і моделі ISO - OSI

 

Структуру комунікаційного середовища PCNC (рис.4) зручно зіставити з класичною багаторівневою моделлю архітектури відкритих систем ISO-OSI [9]. У комунікаційному середовищі прийнято, відповідно до OSACA, виділяти чотири рівня.

· Знизу знаходяться стандартні комунікаційні засоби, що охоплюють фізичний і канальний рівні моделі ISO-OSI. Для двокомпьютерного варіанта подібні засоби можуть бути реалізовані на базі стандартних протоколів Intranet.

· Вище іде рівень MTS (Message Transport System, система транспортування повідомлень); цей рівень виконує функції мережевого і транспортного рівнів моделі ISO-OSI. Для двокомпьютерної системи PCNC у рівень MTS може бути вмонтований чотирерівневий стек протоколів TCP/IP. Система транспортування повідомлень MTS підтримує базові транспортні функції (SEND, RECEIVE) для обміну різноманітними повідомленнями між різними парами модулів. MTS приховує від прикладної частини PCNC як стандартні засоби комунікації (такі, як TCP/IP або ін.), так і усі функції операційної системи, у яких вимагається верхня частина комунікаційного середовища. Модулі, розташовані в різних комп'ютерах, взаємодіють за допомогою MTS так, як якби вони знаходилися в одному комп'ютері. MTS використовує протокол із попереднім встановленням з'єднання. Це означає, що два взаємодіючі MTS-користувачі повинні спочатку встановити з'єднання, а вже потім користуватися ним.

· Вище розташований рівень ASS (Application Services System, система послуг для прикладних програм); цей рівень відповідає сесійному, представницькому і прикладному рівням моделі ISO-OSI. Система ASS надає послуги (із попереднім встановленням з'єднання) прикладним модулям PCNC у такий спосіб. Якщо модуль вимагає віддаленого зв'язку, то ASS формує повідомлення, що містить отриману від модуля інформацію. Далі визивається послуга рівня MTS для посилки повідомлення. На стороні прийому ASS інтепретує повідомлення і передає його модулю-одержувачу. Перед передачею повідомлення ASS підготовляє дані в такій формі, у якій вимагає приймаюча система. Якщо два модулі (або декілька модулів) мають загальну ASS, то вони не потребувають у MTS для підтримки інтерактивності.

· Четвертий рівень лише умовно відноситься до комунікаційного середовища - це прикладний інтерфейс усіх модулів NC-підсистеми, що мають API. Четвертий рівень реалізований як диспетчер комунікаційних об'єктів COM (Communication Object Manager), що асоційований із кожним модулем, що має API. Диспетчер COM являє собою оболонку, наповнену програмами, призначеними для створення, знищення й активізації так званих "комунікаційних об'єктів".

 

4. Взаємодія модулів прикладної компоненти

Зовнішні інтерфейси прикладних модулів являють собою набір комунікаційних об'єктів, що працюють у середовищі диспетчера COM. Набори об’єктів породжуються двома класами (згаданими вище), що формують API (класи "об’єкт-перемінна" і "об'єкт-процес"); а також і двома додатковими класами:

· "об'єктом-подією" для автоматичного повідомлення про зміну значень перемінних при асинхронних транзакціях (сесіях) між клієнтом і сервером;

· "об’єктом-транзакцією" (тільки на стороні клієнта), що містить функції опрацювання даних, одержуваних клієнтом у свої об'єкти класу "об’єкт- перемінна" (вивід на екран, обчислення й ін.).

При такій побудові зовнішніх інтерфейсів вони легко доступні як для клієнта, так і для сервера. Якщо клієнт бажає одержати доступ до інформації сервера (прочитати, записати), то необхідно передбачити комунікаційний об'єкт Cco (Client communication object) на стороні клієнта і цей об'єкт повинен відповідати серверному комунікаційному об'єкту Sco (Server communication object). Повинен бути, принаймні, один Cco, що запитує послуги в Sco. Cco різних прикладних модулів можуть бути одночасно пов'язані з тим самим Sco.

Наприклад, серверний комунікаційний "об’єкт-перемінна" ScoVariable зберігає дані відповідної серверної перемінної. У кожного клієнта є інший комунікаційний "об’єкт-перемінна" CcoVariable, використовуючи який клієнтський додаток має прямий доступ до серверних даних в ScoVariable і можливість відображення в себе цих даних (рис.5).

 
 

Рисунок 5. Приклад доступу клієнтського додатка до даних серверу

 

 
 

Точно так само комунікаційний "об'єкт-процес" ScoProcess на стороні серверу цілком визначає автомат станів серверу з усіма серверними переходами (рис.6). Комунікаційний "об'єкт-процес" CcoProcess на стороні клієнта використовується для керування автоматом стану шляхом виклику передбачених дій (actions).

Рисунок 6.Приклад керування з боку клієнтського додатка переходами між станами серверу

 

Взаємодія клієнта і сервера носить характер синхронної або асинхронної транзакції (рис.7). При посилці синхронного запиту, що запитує Cco очікує відповіді від Sco і залишається заблокованим, поки не надійде підтвердження від запитуваної послуги. Після відправлення асинхронного запиту додаток продовжує свою роботу, а відповідь від серверу надходить або в міру його готовності, або по події. Останнє означає, що клієнт бажає бути сповіщеним сервером при всякій зміні Sco-Variable або ScoPro-cess. У цьому випадку на стороні серверу динамічно (тобто в процесі роботи) створюється "об'єкт-подія" ScoEvent. Його створення ініціюється "об'єктом-подією" CcoEvent, у якому зазначені перемінна, що спостерігається або процес, що спостерігається. Буває так, що під час асинхронної транзакції відповіді серверу повинні якось опрацьовуватися в клієнта. У цих випадках створюється спеціальний додатковий об'єкт - "обєкт-транзакція" CcoTransaction.

 
 

Рисунок 7. Синхронна й асинхронна транзакції

 

Висновок

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

 

Лекція 4. Сучасні індустріальні системи

 

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

керування процесами й інструментами (33%);

інтерфейс оператор - комп'ютер (37%);

двигуни, приводи і керування рухом (30%).

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

 

1. Організація промислових систем

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

Обчислювальний блок вирішує дві задачі.

Перша - це власне програмне керування на основі моделі реального процесу. Друга - організація інтерфейсу з обслуговуючим персоналом. Тут візуалізується стан об'єкта керування шляхом виводу його параметрів і статистичних даних, а також містяться засоби для ручного керування. Інформація про об'єкт, як правило аналогова, збирається давачами. Деякі з давачів пасивні: керуюча система сама періодично їх опитує. Інші давачі самостійно переривають роботу системи, передаючи їй інформацію. Вплив на регульований процес здійснюється за допомогою електричних або електромеханічних виконавчих механізмів. Наприклад, це може бути вмикання/вимикання вентилятора з метою регулювання температури. Між давачами і виконавчими пристроями, з одного боку, і пристроями цифрової обробки - з іншої, ставляться алфавітно-цифрові (АЦП) і цифро-аналогові (ЦАП) перетворювачі. Крім того, для керування виконавчими пристроями застосовуються програмовані логічні контролери (ПЛК).

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

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

2. Потрібно підключати досить широку номенклатуру зовнішніх пристроїв.

3. Час реакції системи на зміни параметрів об'єкта керування визначається зовнішніми реальними часовими інтервалами (такі системи називаються системами реального часу). Це, зокрема, передбачає підвищену надійність як апаратної, так і програмної частин.

Традиційний підхід виділяє в системах промислової автоматизації п'ять рівнів: ввід/вивід (В/В), керування В/В, диспетчерське управління і збір даних (SCADA), управління виробництвом (MES) і планування ресурсів підприємства (MRP). У такий спосіб при розробці подібних систем вирішуються й апаратні, і програмні задачі: перший і частково другий рівень складають апаратну базу для програмного забезпечення верхніх рівнів.

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

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

Ситуація радикально змінилася після того, як ринок виявив лідерів, що пропонували досить непогані рішення, здатні враховувати побажання інших зацікавлених сторін і готових спонсорувати фахову діяльність по стандартизації таких некомерційних організацій, як IEEE, ISO, IEC (МЭК) і ANSI.

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

З цих причин одним з основних архітектурних рішень для систем промислової автоматизації є магістрально-модульна архітектура, в якій зовнішні модулі (блоки) з’єднуються між собою через спільну магістраль. Першим із міжнародних стандартів на магістральні-модульні системи, що отримав широке визнання, став прийнятий у 1968 році стандарт CAMAC. Сьогодні вже очевидно, що більшість розробників систем промислової автоматизації практично відмовилися від використання нестандартних технічних рішень (їхня частка знизилася до 12%).

.

 

4. Технології VME.

Термін VME розшифровується як VERSA MODULE EUROCARD.

З назви зрозуміло, що VME стандарт об'єднує в собі електричну специфікацію VME - шини і формату EUROCARD.

VME-шина виросла зі стандарту VERSA-шини, розробленої фірмою Моторола для мікропроцесора 68000.

EUROCARD - це термін, який представляє широке сімейство виробів, що базуються на стандартах на роз’єми, друковані плати і стійки.

Технологія шини VME зародилася в 1979 році як специфікація компанії Motorola.

Архітектура VME розвинулась навколо сімейства Motorola 68xxx, але зараз є VME-реалізації для RISC-процесорів, робочих станцій Sun, DEC, HP, SGI, Intel і клона PowerPC. На сьогодні існує більше 375 різноманітних процесорних плат VME, які випускає 61 компанія. З загальної кількості 39% плат центральних процесорів підтримують 64-розрядну передачу даних, 61% - 16- і 32-розрядну.

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

У 1987 р. IEEE (Інститут інженерів по електроніці і радіотехніці), у 1988 р. IEC (Міжнародна електротехнічна комісія) затвердили VME як офіційний стандарт.

Через великий інтерес до стандарту VME при ANSI (Американський національний інститут по стандартизації) у 1993 р. була сформована промислова торгова асоціація користувачів і виробників VME- виробів - VITA (VMEbus International Trad Association), завданням якої є просування технології VME.

З тих пір шина VME одержала декілька редакцій A, B, C, C.1, D.
Сьогодні VMEbus (VersaBus Module Eurocard) - це стандартна, нарощувана апаратно- і програмно-незалежна багатопроцесорна архітектура спряження самих різноманітних пристроїв (процесорів, ЦАП, АЦП, мережевих і графічних контролерів і т.п.), прийнята в якості стандарту IEC (МЭК), ANSI, IEEE і іншими міжнародними і національними організаціями по стандартизації.

Технологія VME дозволяє створювати обчислювальні системи в досить широкому діапазоні виробництв, від настільних комп'ютерів і простих дешевих промислових контролерів до багатопроцесорних супер-ЕОМ, систем керування десятками тисяч аналогових і цифрових каналів вводу/виводу. Не претендуючи на досягнення рекордних показників, VMEbus забезпечує найкраще співвідношення ціна/продуктивність для системи в цілому і надає можливості для нарощування ресурсів.

Після офіційного прийняття стандарту завданням комітету стала підтримка життєздатності VME відповідно до змінних технологічних умов.

Введення нової версії стандарту для 64-розрядної передачі даних - VME64 - показали, що потенціал шини VME далеко не вичерпаний. Новітні реалізації VMEbus забезпечують пропускну здатність 320 Мбайт/с.

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

Конструктивно в основу VMEbus покладений популярний механічний стандарт - Евромеханіка. Кінцева система компонується з функціональних модулів VME, встановлюваних у крейти, кількість яких не обмежена. Крейт являє собою каркас з об'єднуючою магістраллю VME, джерелом живлення і вентиляцією. У кожен крейт можна помістити до 21 модуля VME. Модулі з'єднуються через об'єднуючу плату з нормованим хвильовим опором і термінаторами на кожній сигнальній лінії.

Основні технічні особливості шини VMEbus.

Тип шини: немультиплексована (за винятком редакції D), асинхронна
Розрядність: 8, 16 або 32 біта (64 біта для редакції D)
Тип процесора: процесорно-незалежна.

Максимальна кількість слотів у корзині: 21

Максимальна швидкість: 160 МБайт/с (64 біт, редакція D )

Арбітраж: централізований, багаторівневий

VME використовує технологію створення високонадійних вбудованих магістральних-модульних систем із пасивною об'єднуючою магістраллю.

VME використовує два формати Европлати: 3U (100х160 мм) і 6U (233х160 мм)

VME забезпечує введення/вивід як через передню панель, так і через додаткові задні контакти рознімання J2 формату 6U.

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

VME процесорно і програмно незалежний стандарт. З використанням шини VME сьогодні будуються обчислювальні пристрої на базі процесорів PowerPC, Alpha, Pentium/MMX/PRO/II, MC68, DSP... Може бути використаний великий спектр операційних систем як загального призначення: Windows 3. xx/95/NT, версії UNIX..., так і ОС реального часу: OS9, VxWorks, pSOS+, LynxOS, QNX...

VME підтримує розвиту 7-рівневу систему пріоритетних переривань.

VME використовує стандартний, високонадійний трирядний 96 - pin, штирьковий системний роз’єм DIN 41612.

VME має специфікацію "гарячої заміни" модулів для особливо надійних систем.

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

Сьогодні технологія VME, крім основного стандарту VMEbus/VME64, включає декілька розширень.

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

Широке застосування отримав стандарт вимірювальних систем VXIbus, що підтримують більше 200 закордонних фірм, які випускають понад 500 типів модулів. Для телекомунікацій запропонований стандарт SCSA підшини для обробки цифрової аудіо- і відеоінформації в телефонії. VMEbus використовується як основна керуюча шина системи, а SCSA P2 - для інтерфейсу з телефонними ланцюгами.

 

В даний час нараховується більш 200 виробників апаратури в стандарті VME по усьому світі. Спектр апаратури що випускається це:

- процесори на на основі практично всіх існуючих мікропроцесорних архітектур;

- контролери всіляких мереж;

- величезний спектр стандартних інтерфейсів;

- великий вибір дискретного й аналогового введення - виводу;

- модулі обробки графічної інформації;

- різноманітні інтелектуальні модулі;

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

Апаратура VME знаходить своє застосування практично у всіх областях людської діяльності:

· науці;

· авіації і космосі;

· медицині;

· промисловості;

· радіолокації;

· зв'язку;

 

4.2 Шина PCI і її похідні

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

За основу була взята 32/64-розрядна високопродуктивна шина PCI, локальний інтерфейс підсистеми В/В для надплатних розширень активної материнської плати, що стала стандартом для сучасних ПК. Ця шина має масу переваг: вона не залежить від типу мікропроцесора, може працювати з найшвидшими з них, має велику пропускну здатність і апарат автоконфігурування пристроїв В/В. Зараз PCI активно застосовується в VME-комп'ютерах для підключення периферії.

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

CompactPCI став гідним конкурентом технології VME. Проте CompactPCI - відносно новий стандарт, і деякі необхідні функції в ньому або відсутні (гаряча заміна), або не доведені до кондицій. Крім того, номенклатура продуктів CompactPCI поки невелика, особливо в порівнянні з ринком VME/ISA-устаткування. Тому зараз варто орієнтуватися на низку двох стандартів, використовуючи CompactPCI як недорогу об'єднуючу панель із високою швидкістю передачі даних.

 

5. Мезонинні технології

Мезонинні технології застосовуються достатньо давно: у середині 80-х не було засобу запаювати на основній платі кристали пам'яті ємністю більш 64 Кбайт, і для збільшення її обсягу використовувалися мезонинні модулі. Зараз, мезонинні технології набули нового змісту - сьогодні це засіб модульного нарощування функціональних можливостей. Узявши за основу типову плату, розроблювач може додати до неї спеціальні користувальні функції, реалізовані в готовому мезонинному модулі.

Таким чином, мезонинні плати представляють ще один, більш низький у порівнянні, наприклад, із модулями VMEbus рівень модульності. Типовий розмір мезонинних плат 50х80 мм. Вони є функціонально закінченими виробами і встановлюються на плату-носій (у стандарті VMEbus, ISAbus або іншому). Стандартні установочні габарити плати при цьому не змінюються - мезонини встановлюються поверх неї. Носій може бути пасивним або містити власний процесор. Так, мабуть, самий популярний у світі одноплатний комп'ютер/контролер MVME162 крім звичайних аксесуарів (CPU MC68040, Ethernet, SCSI, DRAM, RTC, 2xRS232, Flash-диск, EPROM, VME64) має порти для установки 4 мезониних плат. Це дозволяє доповнити плату комп'ютера, наприклад, 192 каналами цифрового введення/виводу, спецпроцесорами TMS32040, графікою, мережею.

Існує широка номенклатура (http://www.groupipc.com) мезонинних плат: багатоканальні ЦАП, АЦП, цифровий ввід/вивід, EEPROM/FLASH, SRAM, графічні контролери, різноманітні типи мереж, інтерфейс PCMCIA і т.д. Хоча дотепер досить активно застосовуються приватні мезонинні інтерфейси, особливо широко розповсюджені декілька стандартів: PCI Mezzanine Card (PMC), IndustryPack (IP) і ModPack.

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

Історія виникнення стандартних мезониних контролерів

Мезонинні технології використовувалися у світі вже з початку 80-х років у вигляді “частнофірмених” рішень. Згодом назріла необхідність створення стандарту на мезоніни, і тоді вперше у світі фірмою SBS був розроблений стандарт мезонинного модуля вводу-виводу Industry Pack (IP). Це послужило тим якісним поштовхом, що призвів до появи сотень мезонинних контролерів, що випускаються десятками фірм у Європі й Америці, що був підтриманий найбільшими виробниками базових засобів для керуючих систем, такими як Motorola, FORCE, Ariel, якSP ResearchMOTOROLAWavetron, Acromag, Gespack, Prolog, Ziatech, у якості базового стандарту мезонинної шини для своїх інтелектуальних вмонтованих контролерів. Зараз специфікації логічного інтерфейсу IP-контролерів офіційно затверджені (стандарт ANSI/VITA-4-95) у комітеті стандартизації (VSO) міжнародної асоціації VITA і підтримуються міжнародними професійними асоціаціями PCI Industrial Computer Group (PICMG), GroupIPCI

Специфікації IndustryPack

IP-контролери - це невеликі по розміру (45 мм х 99 мм) модулі введення/виводу (див. Рис. 2), що надають користувачу надзвичайно гнучкий і зручний інтерфейс, функції управління різноманітними пристроями, можливості аналогових і цифрових перетворень і т.д. На модулі формату 6U шини VME може бути встановлено до 4-х IP-контролерів. Також вони можуть використовуватися в комп'ютерах, що використовують шини ISA, EISA, Futurebus, G64/96, Multibus, PCI, CompactPCI і Nubus.

IP-специфікації функціонально повні і конкретні. Підтримуються інтерфейси роботи з 2-х портовою пам'яттю, обробка переривань і прямий доступ до пам'яті (DMA). Базові IP-специфікації визначають швидкості передачі по IP-шині 8 або 32 МБ/сек. На кожному IP-контролері встановлюється конфігураційний постійний запамятовуючий пристрій, що містить інформацію про тип контролера, ім'я фірми-виробника, початкові параметри і т.д.

CMOS-технологія забезпечує низький рівень розсіювання потужності як IP-контролера, так і плати-носія.

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

6. Польові системи

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

Такий зв'язок можна було б реалізувати, наприклад, за допомогою мережі Ethernet, але до промислових мереж пред'являються особливі вимоги по надійності і завадостійкості. Для зв'язку з віддаленими цифровими пристроями промислового призначення прийнято використовувати біт-послідовні промислові або польові шини (bit serial Fieldbus). До цієї групи відносять декілька європейських (PROFIBUS (DIN 19245), FIP (UTE-C46-6xx), Bitbus (IEEE 1118), CAN (ISO/DIS 11898), Interbus-S (DIN 9258)) і американських (Foundation, HART) конкуруючих стандартів. Ведеться розробка загальноєвропейського стандарту EN 50170, що об'єднує PROFIBUS і FIP.

Які основні можливості лідера - PROFIBUS? Це відкритий стандарт, що визначає обмін інформацією з компонентами автоматизації будь-яких різновидів - ПЛК, ПК, панелями оператора, датчиками і силовими приводами. Існує три основних варіанти PROFIBUS: FMS, DP і ISP.

PROFIBUS-FMS являє собою рішення для задач взаємодії на цеховому і польовому (field) рівні ієрархії промислових зв'язків: із його допомогою організується обмін між інтелектуальними field-устроями і контролерами, а також між контролерами. Як правило, на цьому рівні обмін інформацією здійснюється по запиті прикладного процесу і не є циклічним. Тому час реакції тут не дуже істотний, набагато важніше функціональні можливості.

Модель PROFIBUS дозволяє визначити комунікаційні зв'язки, що об'єднують розподілені прикладні процеси в один загальний. Та частина прикладного процесу field-пристрою, що відповідає за взаємодію, називається віртуальним field-пристроєм (VFD). Всі об'єкти реального пристрою, із якими можна взаємодіяти (змінні, програми, діапазони даних), називаються об'єктами комунікації. Відображення функцій VFD на реальний пристрій забезпечується в комунікаційній моделі PROFIBUS інтерфейсом прикладного рівня. Для цього об'єкти комунікації PROFIBUS-станції вводяться в її локальний словник об'єктів - OD. Конфігурація OD може визначатися і завантажуватися в пристрій або його виробником, або розроблювачем -- або може формуватися динамічно. OD містить структуру і типи всіх об'єктів, а також їхньої внутрішні адреси в пристрої й представлення на шині (індекс/ім'я). Доступ до об'єктів при функціонуванні відбувається через сервісні функції протоколу PROFIBUS-FMS, що дозволяють, наприклад, опитати/установити значення змінних і масивів, запустити/зупинити програму.

Що стосується двох інших варіантів стандарту, то PROFIBUS-DP - це оптимізована по продуктивності версія PROFIBUS, призначена спеціально для взаємодій, критичних за часом. PROFIBUS-ISP - проект взаємодіючих частин, базується на технології PROFIBUS і доповнює її можливостями управління процесами, включаючи внутрішній захист.

<== предыдущая лекция | следующая лекция ==>
Переваги і недоліки КІТ | Напівпромислові системи на основі шини РСІ
Поделиться с друзьями:


Дата добавления: 2014-01-06; Просмотров: 605; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.269 сек.