Переваги і недоліки КІТ

Характеристика задач програмного керування комп’ютерно-інтегрованих технологій

Задачі програмного керування, що реалізуються з використанням комп'ютерно-інтегрованих технологій, поділяються на:

• геометричні - керування формоутворенням;
• логічні - керування дискретною автоматикою верстату чи виробництва;
• технологічні - керування робочим процесом, характерні для адаптивних систем;
• термінальні - взаємодія з навколишнім середовищем: діалог, обмін інформацією з ЕОМ верхнього рівня.

• 1. Основні переваги КІТ:
• Неприв'язаність до дистанції керування (завдяки технології Ethernet).
• Можливість тотального управління на всіх рівнях виробництва(підприємства)
• Зменшення витрат на робочу силу, зниження вірогідності помилок людини(людського фактору)

• 2. Недоліки КІТ:
• Висока вартість обладнання, встановлення
• Необхідність висококваліфікованого персоналу
• Не всі процеси виробництва можливо автоматизувати за допомогою КІТ

Лекція 2. Операційні системи реального часу систем управління технологічним обладнанням

1. "Жорсткі" і "м'які" системи реального часу

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

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

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

У залежності від відношення до запізнень системи реального часу діляться на "жорсткі" (hard) і "м'які" (soft).

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

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

У м'якій системі реального часу: підвищується вартість запізнення; припускається низька продуктивність у випадку запізнення.

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

Отже, різниця між жорсткою і м'якою системами залежить від вимог, що ставляться до них. Система називається жорсткою, якщо "система не повинна спізнюватися ніколи", і м'якою, якщо "система не повинна спізнюватися, як правило".

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

ОС реального часу: OS-9, VRTX/Vectra, VxWorks, PDOS, pSOS+, Lynx OS, VMEexec, iRMX, С-Ехес і ін. Ці ОС характеризуються, насамперед, малим нормованим часом реакції на зовнішню подію. Це надзвичайно важливо при побудові систем, що працюють у РЕАЛЬНОМУ ЧАСІ: бортової авіаційної апаратури, багатоканальних системах зв'язку, системах управління ракетними і радіолокаційними комплексами, різноманітних промислових і наукових установок, авіаційно-космічних іспитових і тренажерних комплексів і т.п. Як правило, це багатокористувацькі, багатозадачні операційні системи, виконані за технологією мікроядра. Самі нові версії ОС мають мікроядро з перериваннями, що дозволяє гарантувати малий час реакції на зовнішнє переривання при будь-якому стані системи. Відмінною рисою більшості подібних ОС є можливість 100% розміщення в ПЗУ/ППЗУ/ФЛЕШ-памяті самої ОС, мережевого і графічного забезпечення, драйверів, прикладних програм і т.д. Це надзвичайно важливо для вмонтованих бездискових систем. Компанії-виробники, підтримують на своїй апаратурі відразу декілька ОС реального часу.

ОС загального призначення: UNIX/Al/Solaris/HP-UX, MS-DOS, Windows/NT, OS7, OS/2, VMS, RSX11M, XENIX і т.д. Дуже часто ОС загального призначення використовуються в якості середовища для розробки прикладного програмного забезпечення для цільової ("target") системи управління реального часу, де в якості керуючого середовища використовується стандартна ОС реального часу.

2. Необхідні вимоги до ОС для забезпечення передбачуваності

Вимога 1. ОС РЧ повинна бути багатонитковою і допускати витіснення процесів (preemtible).

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

Вимога 2. Диспетчеризація повинна здійснюватися на базі пріоритетів.

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

Вимога 3. Механізм синхронізації ниток повинен бути передбаченим.

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

Вимога 4. Повинна існувати система успадкування пріоритетів.

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

Щоб уникнути цього, ОС РЧ повинна допускати "успадкування" пріоритету, підштовхуючи нитку з нижчим пріоритетом. Успадкування пріоритету означає, що блокуюча нитка, успадковує пріоритет нитки, котру вона блокує (звичайно, тільки якщо остання має більш високий пріоритет).

Вимога 5. Часові характеристики ОС повинні бути передбачувані і відомі.

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

Дата добавления: 2014-01-06