Це зрозуміло при співставленні відношень

, (3.39)

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

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

Такий недолік легко усунути об’єднавши два рівняння

(3.40)

ПІ-закон регулювання, ПІ-регулятор.

Широко використовуються в CAP загальнопромислового призначення. При вірному проектуванні тобто підборі елементів, ПІ-регулятор володіє добрими властивостями в перехідних режимах за рахунок складової , то наявність інтегруючої складової дозволяє позбутися статичної похибки

(3.41)

Введення похідної в закон регулювання є потужним засобом покращення в перехідних режимах

(3.42)

ПД-регулятор реагує не тільки на зміну похибки, але і на зміну її тенденції похідної.

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

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

Моделюємо скоректовану систему (рисунок 3.5).

Рисунок 3.5 – Модель скоректованої системи регулювання ТГ

Структурні схеми та графічне відображення в додатку В (дам Simulink).

4 РОЗРАХУНОК ПОКАЗНИКІВ НАДІЙНОСТІ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

Період життя будь-якої системи (обладнання, виробу) характеризується інтервалами, коли вона виконує покладені на неї функції і коли вона не може через деякі причини їх виконувати. Поняття надійності виникло через необхідність оцінки здатності працювати необхідний час із заданою якістю [16].

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

Джерелом помилок програмного забезпечення є логічні помилки в проекті чи його недосконалість, неправильне кодування.

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

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

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

В даний час відсутні стандартні методи розрахунку надійності програмного забезпечення, тому для аналізу надійності програмного забезпечення використовують експериментально-аналітичні методи прогнозування надійності програмного забезпечення за результатами випробовувань, що базуються на тих чи інших припущеннях. Найпростішою є модель Шумана [35].

Для прогнозування надійності програмного забезпечення в цій моделі використовуються дані про число помилок, що були виправлені в процесі компанування програм в систему програмного забезпечення і налагодження програм. За цими даними обчислюються параметри моделі надійності, яка може бути використана для прогнозування показника надійності в процесі використання програмного забезпечення [35].

Модель заснована на наступних припущеннях:

- в початковий момент компанування програм в систему програмного забезпечення в них міститься Е0 помилок; в процесі коректування нові помилки не вносяться;

- загальне число машинних команд І в програмах постійне;

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

, (4.1)

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

Таким чином, в моделі розрізняють два значення часу: час налагодження і час роботи програми t - сумарне напрацювання програми. Час налагодження містить затрати на контрольні перевірки, виявлення помилок за допомогою тестів та інше. Час справного функціонування при цьому не враховується.

Таким чином, значення інтенсивності відмов вважається постійним впродовж всього часу функціонування (0, t).

В силу прийнятих припущень для фіксованого ймовірність відсутності помилок програми впродовж часу напрацювання (0, t) визначається наступним співвідношенням:

. (4.2)

Для практичного використання формул необхідно оцінити С і Е0 по експериментальним даним. Застосовуючи метод моментів і розглядаючи два періоди відлагодження програми 1 < 2, отримаємо наступні співвідношення:

, (4.3)

, (4.4)

, (4.5)

де n1 і n2 – кількість помилок в програмному забезпеченні, виявлених відповідно в періодах 1 і 2, T1 і Т2 – тривалості роботи системи, що відповідають 1 і 2.

Для визначення кількості команд, що містяться в розробленій програмі скористаємось статистичними відомостями про те, що одна команда в середньому займає 3 байта, 15 % в розмірі ПЗ припадає на різного роду вхідні дані. З врахуванням