Розрахунок надійності апаратно-програмного забезпечення. Розрахунок надійності системи. Кількісна модель оцінки надійності ПЗ

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

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

Розміщено на http://www.allbest.ru/

Вступ

На сьогодні найсерйозніша проблема обробки даних - це проблема програмного забезпечення.

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

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

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

1 . Теоретична частина

1.1 Основні визначення

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

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

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

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

Мал. 1.1. Характеристики, що визначають надійність ПЗ

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

Відновлюваність характеризується повнотою та тривалістю відновлення функціонування програм у процесі перезапуску (рестарту).

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

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

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

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

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

Формулювання основних понять, що використовуються при дослідженні та застосуванні показників надійності;

Виявлення та дослідження основних факторів, що визначають характеристики надійності складних програмних комплексів;

Вибір та обґрунтування критеріїв надійності для комплексів програм різного типу та призначення;

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

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

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

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

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

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

Перевірку працездатності системи та можливості виконання всіх функцій у заданому режимі роботи у будь-який момент часу;

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

1.2 Класифікація моделей надійності

p align="justify"> Для кількісної оцінки показників надійності програмного забезпечення використовують моделі надійності, під якими розуміються математичні моделі, побудовані для оцінки залежності надійності від заздалегідь відомих або визначених в ході виконання завдання параметрів. Потрібно ретельно вибирати методики з метою оцінки надійності програмного забезпечення. Необхідно враховувати їхню придатність для різних стадій життєвого циклу, встановлення порядку їхнього спільного використання для визначення надійності програмного забезпечення протягом усього його життєвого циклу.

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

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

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

Розглянемо існуючу класифікацію моделей надійності програмного забезпечення (рис. 1.2).

Мал. 1.2. Класифікація моделей надійності програмного забезпечення

1.2.1 Безперервні динамічні моделі

Нехай функціонування програмного забезпечення описується графом станів, зображеним малюнку 1.3. Тут S i – стан системи, коли відбувся i-й за рахунком відмова, l i – інтенсивність наступу наступної ((i+1)-го за рахунком) відмови.

Мал. 1.3. Граф станів функціонування програмного забезпечення

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

де r<1. Значения l 0 и r можно оценить статистически по данным о моментах отказов.

Пояснимо процеси, що відбуваються під час відмов та відновлення ПЗ. Якщо прийняти l i як випадкову величину з функцією розподілу l(t), то ця функція - монотонно спадаюча, тому що в часі інтенсивність відмов зменшується. Після виправлення миттєва інтенсивність відмов різко зменшується стрибком (точки 1 та 2 на рис. 1.4).

Мал. 1.4. Графік залежності інтенсивності відмов від часу

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

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

Відповідно до цих припущень ймовірність безвідмовної роботи програмного забезпечення як функція часу t i дорівнює:

де інтенсивність відмов:

Тут C D – коефіцієнт пропорційності;

N – початкова кількість помилок.

У (1.1) відлік часу починається з моменту останньої (i - 1)-го відмови програми.

За методом максимуму правдоподібності на підставі (1.1), позначаючи через k номер прогнозованої відмови, отримаємо, що функція правдоподібності має вигляд:

Логарифмічна функція правдоподібності має вигляд:

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

З (1.6) отримаємо:

Підставимо (1.7) до (1.5). Отримаємо:

При відомих значеннях k; t 1 , t 2 , …, t k з (1.7) і (1.8) можна знайти значення параметрів моделі C D і N, а потім інтенсивність відмов, час від останньої до наступної відмови t k+1 , ймовірність безвідмовної роботи через час t k+ 1 після останньої відмови.

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

приклад розрахунку. Нехай під час налагодження зафіксовані інтервали часу t 1 =10, t 2 =20, t 3 =25 годин між відмовами програми. Необхідно визначити ймовірність:

а у правій частині:

З (1.2) отримуємо

Отже, середній час до наступної відмови складає:

Тоді, підставляючи знайдені значення l 4 і t 4 (1.1), отримаємо ймовірність відсутності четвертої відмови:

Модель перехідних ймовірностей Маркова.Модель дозволяє отримати оцінки та передбачення ймовірного числа помилок, які будуть виправлені в заданий час, на основі попереднього моделювання інтенсивності помилок l, що трапляються, а також прийнятої системи виправлення помилок, що працює з інтенсивністю m. Модель дозволяє отримати передбачення для готовності A(t) та надійності R(t) системи ПЗ.

Приймаються такі основні обмеження моделі, що розробляється:

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

Інтенсивність прояву помилок стала і дорівнює l;

Інтенсивність виправлення помилок постійна та дорівнює m;

час переходу системи з одного стану до іншого нескінченно мало.

Розглянемо систему, що починає роботу в момент часу t = 0. Система працює до появи помилки відповідно до визначеного критерію. Результати експерименту збираються у відрізки часу, які можуть статися відмови у роботі. Тоді змінна часу випадкового збою може бути визначена як:

де - місце розташування точок на дискретної тимчасової осі експерименту. Припустимо, що випадкова змінна має функцію розподілу:

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

Надійність системи R(t) визначається ймовірністю відсутності збою в інтервалі:

Під готовністю системи на момент часу t розуміється ймовірність того, що система знаходиться в робочому стані під час t:

Припустимо, що у початковий період (t = 0) система містить невідоме число (п) помилок. Як початок відліку часу роботи системи вибирається початок фази тестування. Приймаємо також, що процеси виявлення та виправлення помилок реалізуються поперемінно та послідовно.

Мал. 1.5. Модель багатьох станів для оцінки характеристик ПЗ

Ряд станів системи (n, п – 1, п – 2, …) відповідає процесам виявлення помилок. За аналогією для випадку усунення помилок введемо стан системи (т, т - 1, т - 2, ...). Система перебуває у стані (п - k), якщо помилка (k - 1) вже виправлено, а помилка k ще виявлено. У той же час система перебуватиме в стані (т - k) після того, як помилка k виявлена, але ще не виправлена. Загальна схема моделі із зазначенням ймовірностей переходу між станами показано на рис. 1.5.

Нехай S"(t) є випадковою змінною, через яку позначено стан системи в момент часу t. Експеримент буде побудований так, що в деякий момент часу припускаємо систему зупиненої і спостерігаємо її стан. Простір можливих станів S системи може бути представлений так:

Тепер припустимо, що в моменти (будь-яка послідовність спостережень) послідовність випадкових змінних задовольняє для будь-якого позитивного цілого числа наступної рівності:

де відповідають послідовності станів

Таким чином, будь-який стан моделі визначається рядом перехідних ймовірностей (P ij ), де P ij позначає ймовірність переходу зі стану i стан j і не залежить від попередніх і наступних станів системи, крім станів i і j. Імовірність переходу зі стану (п - k) до стану (т - k) дорівнює при k = 0, 1, 2, … Аналогічно цьому можливість переходу зі стану (т - k) до стану (п - k - 1) дорівнює при k = 0, 1, 2, …

Інтенсивність переходу l j і m j залежить від поточного стану системи. Для системи ПО l j означає інтенсивність виникнення (прояви), a m j – інтенсивність усунення помилок. Отже, повна матриця перехідних ймовірностей системи може бути представлена ​​таким чином:

Вираз для готовності системи під час t(tі0) отримаємо на основі її визначення:

Готовність системи під час t визначається як результат простого додавання всіх ймовірностей станів зайнятості.

Надійність системи залежить від рівня її налагодження, тобто. чим ступінь налагодження системи, тим більша очікувана надійність. Припустимо, що на момент t система щойно ввійшла у стан (n - k), т. е. помилка k щойно усунена. Назвемо цей час як t. Тоді в інтервалі часу (0, T k+1), де t = T k+1 може виявитися помилка (k + 1) за прийнятої постійної інтенсивності прояву помилок l k .

На підставі формули функції надійності, що породжує ймовірність відсутності збоїв в інтервалі часу від 0 до t,

отримаємо вираз для надійності:

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

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

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

приклад розрахунку. Нехай під час налагодження зафіксовані інтервали часу t 1 =10, t 2 =20, t 3 =25 годин між відмовами програми. Система перебуває у стані, коли помилка 3 вже виправлена, а помилка 4 ще виявлено. Необхідно визначити ймовірність:

відсутності наступної (четвертої) відмови.

Тут годинник - це час, коли остання виявлена ​​помилка виправлена.

Величину l i визначимо за моделлю Джелінскі-Моранди (формула (1.2)):

Значення C D і N визначимо за формулами (1.7) та (1.8).

Початкова кількість помилок N знаходимо методом підбору. Якщо N=3, тобто виявлено всі помилки, то лівій частині (1.8) маємо:

а у правій частині:

Якщо N=4, ліва та права частини відповідно дорівнюють 152 та 150. Якщо N=5, відповідно 210 та 205.

Отже, найменшу помилку під час вирішення (1.8) забезпечить N=4, звідки за такою формулою (1.7):

З (1.2) отримуємо:

Тоді, підставляючи знайдене значення l 4 (1.19), отримаємо ймовірність відсутності четвертої відмови:

1.2.2 Дискретні моделі

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

МОДЕЛЬ ШУМАНУ. У цій моделі передбачається, що тестування проводиться у кілька етапів. Кожен етап є виконання програми з набору тестових даних. Виявлені протягом етапу тестування помилки реєструються, але не виправляються. Після завершення етапу виправляються всі виявлені цьому етапі помилки, коригуються тестові набори і проводиться новий етап тестування.

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

Нехай проводяться до етапів тестування. Позначимо тривалість кожного етапу через t 1 , …, t k , а кількість помилок, виявлених кожному етапі, через m 1 , …, m k .

Нехай T = t 1 + … + t k – загальний час тестування; n = m 1 + … + m k - загальна кількість виявлених та виправлених при тестуванні помилок; n i = m 1 + … + m i - Число помилок, виправлених до початку (i + 1)-го етапу тестування (n 0 = 0).

У моделі Шумана програмне забезпечення на i-му етапі тестування має функцію надійності:

N – початкова кількість помилок у програмному забезпеченні;

N – n i-1 – кількість помилок, що залишилися до початку i-го етапу;

C - коефіцієнт пропорційності, рівний:

Для знаходження початкової кількості помилок у програмному забезпеченні N використовується рівняння:

При відомих значеннях k; t 1, t 2, …, t k; m 0 , m 1 , …, m k з (1.21) та (1.22) можна знайти значення параметрів моделі C та N. Після чого можна визначити наступні показники:

1) кількість помилок, що залишилися в програмному забезпеченні:

2) функцію надійності програмного забезпечення після завершення тестування:

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

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

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

Методом підбору з рівняння (1.22) виявимо, що початкова кількість помилок.

Знайдемо кількість помилок, що залишилися в програмному забезпеченні за (1.23):

За формулою (1.21) знайдемо значення параметра C:

Підставляючи l (1.24), отримаємо функцію надійності програмного забезпечення після завершення тестування:

МОДЕЛЬ МУСА. У цій моделі надійність програмного забезпечення на етапі експлуатації оцінюється за результатами тестування.

Нехай T - сумарний час тестування, n - кількість відмов, що сталися під час тестування.

Тоді за моделлю Муса середнє напрацювання до відмови після тестування на етапі експлуатації визначається за формулою:

де t 0 - середнє напрацювання до відмови до початку тестування, C - коефіцієнт, що враховує ущільнення тестового часу в порівнянні з часом реальної експлуатації. Наприклад, якщо одна година тестування відповідає 12 год. роботи в реальних умовах, то C = 12.

Невідомий параметр t 0 можна оцінити з наступного співвідношення:

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

K – коефіцієнт прояву помилок. Значення K визначається емпіричним шляхом за однотипними програмами. Зазвичай це значення змінюється від 1,5×10 -7 до 4×10 -7;

f - середня швидкість виконання одного оператора програми, що дорівнює відношенню середньої швидкості виконання програмного забезпечення (A) до команд (операторів) (B).

Надійність програмного забезпечення для періоду експлуатації t визначається за такою формулою:

Переваги та недоліки моделі. До переваг моделі можна віднести те, що немає потреби фіксувати моменти відмов. У разі відмов помилки реєструються, а виправляються лише після завершення етапу тестування.

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

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

Знайдемо середню швидкість виконання одного оператора:

Початкова кількість помилок у програмному забезпеченні N знайдемо за моделлю Шумана методом підбору з рівняння (1.22): найменша відмінність значень правої та лівої частин цього рівняння досягається при. Отже, це і є початкова кількість помилок програмного забезпечення.

Коефіцієнт прояву помилок K приймемо рівним.

Знайдемо значення параметра t 0 (1.26):

Приймемо значення коефіцієнта.

Тоді середнє напрацювання до відмови після тестування на етапі експлуатації (1.25):

Знайдемо надійність програмного забезпечення для періоду експлуатації годинника за формулою (1.27):

1.2.3 Статичні моделі

Статичні моделі відрізняються від динамічних передусім тим, що не враховується час появи помилок.

МОДЕЛЬ МІЛЛСА. Використання цієї моделі передбачає необхідність перед початком тестування штучно вносити у програму кілька відомих помилок. Помилки вносяться випадковим чином та фіксуються у протоколі штучних помилок. Спеціаліст, який проводить тестування, не знає ні кількості, ні характеру внесених помилок. Передбачається, що всі помилки (як природні, так і штучні) мають рівну можливість бути знайденими в процесі тестування.

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

Нехай після тестування виявлено n власних помилок програми та v штучно внесених помилок. Тоді початкове число помилок у програмі N можна оцінити за формулою Міллса:

де S – кількість штучно внесених помилок.

Друга частина моделі пов'язані з перевіркою гіпотези про N. Припустимо, вважаємо, що у програмі спочатку K помилок. Вносимо штучно в програму S помилок і тестуємо її доти, доки всі штучно внесені помилки не будуть виявлені. Нехай у своїй виявлено n власних помилок програми. Імовірність, що у програмі спочатку було K помилок, можна розрахувати за співвідношенням:

Формулу (1.29) можна використовувати тільки у випадку, якщо виявлені всі S штучно внесених помилок. Якщо ж виявлено лише v штучно внесених помилок, то застосовують формулу:

Число поєднань з n елементів m.

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

Однак є недоліки:

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

2) досить вільне припущення величини K, яке ґрунтується виключно на інтуїції та досвіді людини, яка робить оцінку, тобто допускає великий вплив суб'єктивного фактора.

Приклад розрахунку 1. У програму внесено 50 помилок, й у процесі тестування виявлено 25 власних і 5 внесених помилок, за формулою Міллса (1.28) робиться припущення, що у програмі їх було.

Приклад розрахунку 2. Стверджується, що у програмі немає помилок (K = 0). При внесенні до програми 10 помилок усі вони у процесі тестування виявлено, але при цьому не виявлено жодної власної. Тоді за формулою (1.29) ймовірність, що це твердження вірне, дорівнює. Таким чином, із ймовірністю 0,91 можна стверджувати, що у програмі немає помилок. Але якщо в процесі тестування виявлено хоч одну власну помилку, то p = 0.

Приклад розрахунку 3. Стверджується, що у програмі немає помилок. На момент оцінки надійності виявлено 5 із 10 штучно внесених помилок, і не виявлено жодної власної. Тоді ймовірність того, що у програмі дійсно немає помилок, обчислюється за формулою (1.30) і дорівнює:

Якщо за тих же вихідних умов оцінка надійності проводиться в момент, коли виявлено 8 із 10 штучних помилок, то за формулою (1.30)

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

У моделі передбачається, що область, якій можуть належати вхідні дані програми, розділена на k областей, що не перетинаються Z i , i = 1, 2, …, k. Нехай pi - ймовірність того, що для чергового виконання програми буде обраний набір даних з області Z i . Значення pi визначаються за статистикою вхідних даних у реальних умовах роботи програмного забезпечення.

Нехай до моменту оцінки надійності було виконано n i прогонів програмного забезпечення на наборах даних з області Z i і з цих прогонів закінчилися відмовою.

Тоді надійність програмного забезпечення оцінюється за такою формулою:

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

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

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

де n + - Число успішних прогонів програмного забезпечення;

Число виявлених помилок i-го типу, що усуваються з ймовірністю p i ;

d i - коефіцієнт, який визначається наступним чином:

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

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

Приклад розрахунку за узагальненою моделлю Нельсона - Коркорена. Загальна кількість прогонів програмного забезпечення, кількість прогонів, які закінчилися відмовою, .

Надійність визначається за формулою (1.34):

1.2.4 Емпіричні моделі

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

Найбільш проста емпірична модель пов'язує кількість помилок у програмному забезпеченні з його обсягом. Досвідчені дані свідчать, що до початку системного тестування у програмному забезпеченні на кожні 1000 операторів припадає приблизно 10 помилок. Рівень надійності програмного забезпечення вважається прийнятним для початку експлуатації, якщо тому обсягу операторів буде відповідати одна помилка.

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

де M 10 - число модулів, які вимагали 10 і більше виправлень;

M 1 - число модулів, у яких виявлено менше ніж 10 помилок.

Застосовується також емпірична формула для оцінки середнього напрацювання програмного забезпечення на відмову:

де t - середнє напрацювання програмного забезпечення на відмову в годинах;

V ОП – обсяг програми в операторах;

N - число помилок у програмному забезпеченні, оцінене за однією з наведених вище моделей;

a - коефіцієнт, що у діапазоні від 100 до 1000.

приклад розрахунку. Число модулів, що зажадали 10 і більше виправлень, дорівнює кількість модулів, в яких виявлено менше 10 помилок, дорівнює. Знайдемо число помилок у П N за формулою IBM (1.35):

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

де N ЗОШ - число помилок у програмі;

K АЛЕ - коефіцієнт пропорційності;

V ОП - число операторів у програмі;

h 1 - Число операторів у програмному засобі;

h 2 - число операндів у програмному засобі;

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

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

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

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

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

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

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

1.3 Аналіз надійності програмних комплексів

Оскільки між надійністю та складністю програмного забезпечення існує тісний зв'язок, то проблем надійності стосується ще одна група моделей – моделі, призначені для оцінки складності програмного забезпечення. Ці моделі оцінюють безліч характеристик програмного забезпечення, таких як довжина програми, інформаційний зміст, кількість підсистем, кількість операторів, складність інтерфейсу тощо. Усі існуючі моделі складності та метрики показників визначають лише окремі, приватні характеристики складних програм. Спільним поняттям всім видів складних програм є їх структура. p align="justify"> При аналізі структурної складності програмного забезпечення з метою визначення його надійності необхідно проводити багатокрокову процедуру зниження його складності. Поширення складних програмних систем та комплексів потребує нових підходів до оцінки їх надійності. Складність розв'язання цього завдання обумовлена ​​відсутністю універсальних методів та моделей.

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

1.3.1 Графова модель програми

Як графової моделі програми розглянемо орієнтований граф G (V, Г), де V = (vi) - безліч вершин, Г = (g ij) - безліч дуг. Граф системи G(V, Г) визначається структурою програмної системи. Безліч V вершин графа становить програмні модулі (типи модулів), а безліч дуг Г відбиває зв'язок між модулями, тобто, якщо з i-го модуля є перехід у j-ий модуль, то у графі G є дуга g ij , що веде з i -ой вершини в j-у. Введемо модельні обмеження. Припустимо наявність у графовій моделі програми однієї джерельної вершини v 0 (вхід) та однієї — v k (вихід). Допустимо також, що з кожної вершини виходить не більше двох дуг, кількість дуг, що входять у вершину, не обмежується. Будемо вважати, що графова модель програми не містить циклів, а програма, що нею відображається, відноситься до категорії несамозмінних.

При моделюванні обчислювального процесу на графовій моделі програми та дослідженні властивостей програмного забезпечення передбачається повідомлення кожному елементу моделі певної ваги. Припустимо, кожна вершина v i характеризується адитивним елементарним показником d i , пов'язаним з досліджуваним властивістю програми. Введені показники утворюють на графі безліч D = (d i). Модель G(V, Р, D) може використовуватись для статистичного дослідження різних маршрутів графової моделі програми. Вибір шляху прогону на графі обумовлюється сукупністю реалізацій передач управління на вершинах, пов'язані з випадковим процесом надходження на вхід програми різних векторів вхідних даних, що призводить до випадкового характеру вибору маршрутів у графі. Таким чином, досліджуване програмне забезпечення можна уявити складною системою з випадковою структурою, динаміку функціонування якої доцільно описати статистично за допомогою ймовірностей переходу від i-ої до j-ої вершини графової моделі програми.

З огляду на це припишемо дузі g ij ймовірність її активізації p(i, j)ОР, тобто ймовірність відходу по ній з вершини v i у вершину v j . Припустимо, що для двох дуг і справедлива рівність:

Отже, побудована графова модель програми є ациклическим орієнтованим навантаженим графом G(V, Р, D, P).

На рис. 1.6 наведено приклад графової моделі програми. На ньому вершина 0 – це витокова вершина, а вершина 4 – стокова.

1.3.2 Модель Нельсона визначення надійності для графової моделі програми

Для завершальної стадії життєвого циклу програмного комплексу слід використовувати модель визначення надійності із системно-незалежним аргументом (кількість прогонів ПЗ), наприклад, модель Нельсона.

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

З метою використання моделі G(V, Г, D, P) припишемо зазначеним адитивним характеристикам сенс логарифмічної міри ймовірностей r i одноразового безвідмовного виконання послідовності операторів, що асоціюються з вершиною v i:

Тоді можливість безвідмовного виконання маршруту при m-му прогоні програмного забезпечення визначається рівністю:

а її логарифмічний захід:

Використовуючи наближення:

де Q m - ймовірність відмови при виконанні маршруту (ця умова виконується за визначенням), і припущення, маємо:

Оскільки маршрут w m реалізується з ймовірністю p(m), повна ймовірність відмови при виконанні m прогону визначається виразом:

Оцінка середнього значення ймовірності відмови Q m задається рекурентними співвідношеннями:

де p(i) – ймовірність активізації i-ї вершини графової моделі програми.

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

1.3.3 Стохастичний метод обчислення надійності

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

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

Нехай P ij - можливість переходу від i-го програмного модуля до j-го, а P i (t i) - ймовірність безпомилкового функціонування i-го програмного модуля протягом часу t i .

Так як вершини 0 і (M + 1) - фіктивні, припускаємо, що час перебування в них дорівнює нулю, а ймовірності безпомилкової роботи в них - одиниці.

На рис. 1.7 наведено приклад стохастичного графа програмного комплексу. На ньому: вершина 0 – витокова вершина, вершина 4 – стокова, t 0 = t 5 = 0, P 0 (t 0) = P 5 (t 5) = 1.

Розглянемо матрицю G = G(t), t = t 0 , t 1 , …, t M + 1 елементами якої є твори P ij ЧP i (t i); i, j = 0, …, M + 1:

Введемо поняття кроку, маючи на увазі під ним одиничний перехід від одного програмного модуля до іншого.

Нехай n - максимально можливе число кроків шляху від вершини 0 до вершини (M + 1).

Щоб знайти ймовірності безпомилкової роботи за два кроки, потрібно підсумувати з відповідними ймовірностями добутку ймовірностей на всіх шляхах, що містять дві вершини (одна з них нульова). Це досягається зведенням матриці G квадрат. Для отримання ймовірності безпомилкового функціонування три кроки G зводимо в куб і так далі залежно від n.

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

Побудуємо матрицю виду:

T = I + G(t) + G2(t) + … + Gn(t).

Якщо у графі є цикли, то матриця T матиме вигляд:

T = I + G (t) + G 2 (t) + ... = I (I - G (t)) - 1, (1.42)

де I – одинична матриця.

Елемент матриці T з номером (0, M + 1) є виразом для ймовірності безпомилкової роботи всього програмного комплексу з урахуванням всіх можливих послідовностей викликів окремих програмних модулів.

Якщо у графі є цикли, і матриця T відповідає (1.42), то, щоб знайти значення елемента з номером (0, M + 1), відповідно до правил обчислення значень елементів зворотної матриці, вираз для ймовірності безпомилкової роботи програмного комплексу можна представити в вигляді:

Y(t) = Q(t) / R(t), (1.43)

де Q(t) - додаток алгебри елемента з номером (M + 1, 0) матриці; R(t) – головний визначник матриці (I – G(t)).

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

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

приклад розрахунку. Знайдемо значення ймовірності безпомилкового функціонування програмного комплексу, стохастичний граф якого показано на рис. 1.8.

При оцінці ймовірності безвідмовної роботи i-го програмного модуля скористаємося формулою (1.27) з моделі Муса, в яку підставлено вираз для середнього напрацювання повністю після тестування на етапі експлуатації (1.25) (див. п. 1.2.2):

де t i – час роботи i-го модуля;

Середнє напрацювання до початку тестування для i-го модуля;

C - коефіцієнт, що враховує ущільнення тестового часу, порівняно з часом реальної експлуатації;

T i – час тестування i-го модуля;

n i - Число відмов, що відбулися за час тестування i-го модуля.

Відомо, що коефіцієнт тривалості роботи модулів с, с, с. Число відмов, що відбулися в модулях під час тестування: , . Середнє напрацювання до початку тестування для модулів: с, с, с. Ймовірність переходів між модулями: , . Приймемо час тестування модулів: с, с, с.

Скористаємося формулою ймовірності безвідмовної роботи i-го програмного модуля з моделі Муса:

Для даного графа кількість модулів M = 3 (модулі 0 та 4 – фіктивні).

Побудуємо матрицю цього графа (1.41):

Постоїмо матрицю T, яка, оскільки граф містить цикли, матиме вигляд (1.42):

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

Запишемо матрицю:

Значення елемента матриці T з номером (0, 4) знайдемо за формулою (1.43), обчисливши додаток алгебри елемента (4,0) матриці, рівне, і головний визначник матриці, рівний.

Отримаємо, що значення елемента матриці T з номером (0, 4), отже, і можливість безпомилкової роботи всього програмного комплексу дорівнює.

1.3.4 Особливості об'єктно-орієнтованого ПЗ

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

Подібні документи

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

реферат, доданий 21.12.2010


Надійність як характеристика якості програмного забезпечення. Методика розрахунку характеристик надійності ПЗ (таких як час напрацювання до відмови, коефіцієнт готовності, ймовірність відмови), особливості прогнозування їх змін у часі.

дипломна робота , доданий 01.06.2010


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

презентація , доданий 30.04.2014


Дії, що виконуються під час проектування АІС. Кластерні технології, їхні види. Методи розрахунку надійності різних етапах проектування інформаційних систем. Розрахунок надійності із резервуванням. Випробування програмного забезпечення на надійність.

курсова робота , доданий 02.07.2013


Надійність системи управління як сукупність надійності технічних засобів, обчислювальної машини, програмного забезпечення та персоналу. Розрахунок надійності технічних систем, види відмов САУ та ТСА, підвищення надійності та причини відмов САУ.

курс лекцій, доданий 27.05.2008


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

лекція, доданий 22.03.2014


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

презентація , додано 16.10.2013


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

дипломна робота , доданий 18.04.2014


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

презентація , доданий 22.03.2014


Метод імовірнісно-алгебраїчного моделювання. Приклади визначення імовірнісних характеристик функціонально-складної системи символьному вигляді. Отримання та додавання даних із сервера "Всесвітньої організації охорони здоров'я". Структура бази даних

У складі сучасних технічних систем дедалі більшу питому вагу займають кошти обчислювальної техніки. Вартість основного осередку інтегральних мікросхем – логічного вентиля – з розвитком електроніки безперервно знижується. Навпаки, програмне забезпечення, питома вартість якого в перших ЕОМ була дуже малою, нині становить понад 90% вартості комп'ютерів. Це зростання вартості пояснюється кількома причинами:

1) Технологія створення програмного забезпечення серйозно відстає від технології виробництва елементної бази;

2) за своєю природою програмне забезпечення складніше обладнання (обсяг програм для сучасних систем оцінюється у 10 6 – 10 8 і більше команд чи інформаційних слів);

3) вимоги до програмного забезпечення протягом його життєвого циклу, що збільшився до 15 – 20 років, суттєво змінюються;

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

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

Приблизно можна вважати, що відношення числа помилок у програмі до загальної кількості команд у ній лежить у діапазоні від 0,25 до 10 на 1000 команд. Це означає, що у ПЗ обсягом 0,5 млн. команд може бути 125 – 5000 помилок; причому така оцінка є оптимістичною. Виявлення помилок та їх виправлення є процесом багатоетапним (відповідно до етапів «життя» ПЗ), трудомістким і дорогим. У міру початку пізніших етапів розробки ПЗ ціна помилки зростає, тенденцію цього зростання ілюструє таблиця:

Таблиця 2.1 - Орієнтовна «ціна» програмної помилки на різних етапах життя програмного забезпечення

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

2.3.1 Основні визначення теорії надійності програмного забезпечення

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

Основна складність визначення терміна «програмна помилка» полягає в тому, що помилка в програмі – це за своєю суттю функція самої програми та того, чого очікує від неї користувач. Перелічимо основні прояви, які можна ідентифікувати як помилку:

Поява при програмуванні помилкового операнда чи операції;

Невідповідність виконуваних ПЗ функцій вимогам специфікацій, або помилка у специфікації, що призводить до помилки під час виконання ПЗ;

Помилки обчислювального характеру (наприклад, переповнення);

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

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

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

, (2.80)

де - Число виявлених помилок на даному етапі.

Диференціюючи рівняння (2.80) за часом отримаємо

де - є функція ризику. Якщо вирішити диференціальне рівняння , з початковими умовами то

(2.81)

Позначимо Тоді рівняння (2.81) можна переписати як

Функцію ризику поставимо дискретно, надавши інтервалу часу задане значення (день, тиждень, місяць). Логарифмуючи рівняння (2.82) для обраних значень часу, отримаємо систему рівнянь виду

(2.83)

Розрахунок експоненційної регресії дає такі висловлювання на її коефіцієнтів

(2.84)

(2.85)

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

Будемо під питомою інтенсивністю виявлення помилок у ПЗ розуміти таку функцію часу:

(2.87)

де - Число помилок в ПЗ, які виправлені на момент часу t; - Число команд у програмі. Приблизно можна вважати, що

тут – розрядність команди; - обсяг програми з Холстеду, що буде; У– кількість помилок, що залишилися в ПЗ до моменту t = 0; До- Коефіцієнт пропорційності. Величини Уі Доє невідомими.

Розглянемо два періоди налагодження програми Т 1і Т 2такі, що Т 1 < Т 2. Нехай n 1і n 2відповідно кількість помилок у ПЗ, виявлених у кожному з періодів. Тоді для середнього часу безпомилкової (безвідмовної) роботи у кожному з періодів можна записати такі вирази:

(2.89)

(2.90)

Розділивши першу рівність на другу, після перетворень можна отримати:

(2.91)

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

. (2.92)

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

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

Введення можливої ​​комбінації Е iвхідних даних;

Виконання розрахунку за програмою, яка закінчується отриманням результату F(E i)чи відмовою.

Для певного набору вхідних даних відхилення результату від заданого значення F`(E i),отримане в результаті виконання програми знаходиться в допустимих межах

(2.93)

а решти E i , що утворюють підмножина , виконання програми забезпечує прийнятного результату, тобто.

> (2.94)

Події, що описуються нерівністю (2.94), називаються відмовами програми.

Методика статистичної оцінки ймовірності відмови ПЗ за nнезалежних прогонів програми є традиційною і формально включає в себе оцінку

(2.95)

де, якщо виконується нерівність (2.93); якщо виконується нерівність (2.94).

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

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

Для перевірки надійності ПЗ використовуються методи перевірки статистичних гіпотез і, зокрема, послідовний аналіз Вальда. Порівняємо дихотомічною змінною значення 1 , якщо виконується (2.94), та значення 0, якщо виконується (2.93). Тоді результат прогонів утворює вибірку випадкових величин Позначимо можливість, що , тобто. програма відмовляє, як Р; а ймовірність Р 0 того. що набуває значення 0, а програма справна. Тоді вибір значення

Р 0 =0,99 означає, що в серії зі 100 прогонів ймовірно в середньому поява однієї відмови.

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

Велике значення для отримання наближених оцінок показників надійності програмного забезпечення мають так звані метрики Холстеда. Ці метрики дозволяють чисельно оцінити та інші характеристики ПЗ: довжину програми, її обсяг, рівень програми, її інтелектуальне зміст, тривалість розробки тощо. Метрики пройшли серйозну практичну апробацію та показали прийнятну для практичних розрахунків точність. Розглянемо суть методу Холстеда.

Для будь-якої програми можна визначити:

Число різних операцій, наприклад, та ін.;

Загальна кількість всіх операндів (змінних та констант);

Загальна кількість усіх операцій

Загальна кількість усіх операндів

Тоді словник програми є , а довжина реалізації складає Довжина програми в цьому випадку дорівнює

а обсяг програми (2.97)

потенційний обсяг програми

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

Потенційний обсяг – мінімально можливий обсяг певного алгоритму. Рівень програми Lвизначається через відношення потенційного обсягу до обсягу програми

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

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

що дозволяє інакше виразити характеристики Еі V:

У таблиці 2.2 наведено чисельні значення мов різного рівня.

Таблиця 2.2 – Чисельні значення рівня мови

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

чол. - годин; (2.104)

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

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

Коефіцієнт пропорційності Звизначають, з наступних міркувань. Відповідно до емпіричного закону Д. Міллера «7 2» для визначимо, що , а для англійської мови з урахуванням (2.100) отримаємо

що дозволяє оцінити коефіцієнт Зяк

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

що, зокрема, для Ассемблера дає значення Таким чином,

(2.108)

або у більш загальній формі

Значення величин і можуть бути визначені з результатів аналізу ПЗ або опосередковано шляхом вирішення рівнянь Холстеда, якщо відомі значення:

(2.110)

2.3.2 Методика оцінки кількості помилок, що залишилися в програмі

Оцінка потенційного числа помилок у ПЗ перед початком розробки програми може бути проведена шляхом розрахунку кількості незалежних вхідних та вихідних величин, потенційного обсягу програми та можливої ​​кількості помилок у ній. Наведемо приклади аналізу вхідних та вихідних даних.

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

Усього є сорок вхідних величин. Вихідних величин кожному за інформаційного каналу буде чотири (три просторові координати плюс час), тобто. всього 12 незалежних величин.

Рішення.

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

а кількість потенційних помилок у ПЗ дорівнює

приклад 2.Визначити характеристики програмного забезпечення для бойової космічної станції (БКС) системи протиракетної оборони (ПРО) на кшталт стратегічної оборонної ініціативи президента США Рейгана. БКС має бути розрахована на перехоплення близько 1000 цілей з відстані приблизно 400 км.

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

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

Вихідні величини програми – це кутові координати цілей та відстань до них. Для 20 цілей кількість вихідних величин становить

Отже,

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

Розрахунки показують, що для створення такого об'ємного програмного забезпечення потрібно близько 10 12 чол. - годин. Потенційна кількість помилок у цьому гігантському за обсягом ПЗ для мов різного рівня дорівнює:

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

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

Значення складається з команд, використовуваної системи команд і з окремих підпрограм. У ПЗ прикладу використовувалося 45 різних операторів, число підпрограм склало 157. Таким чином,

Кількість операндів дорівнює сумі (різні змінні та масиви даних, що використовуються в ПЗ); плюс кількість локальних міток та констант. Для полегшення підрахунку використовують наявний розподіл пам'яті оперативного пам'яті (ОЗУ), при цьому підході виключається повторюваність відповідних операндів. Число локальних міток підраховують за текстом програми на асемблері ліворуч від мнемонічного запису команди. У такий спосіб гарантується не повторюваність міток, а загальноприйнята табуляція полегшує підрахунок. Складніше порахувати кількість різних констант, які оформлюються в масиви числових даних і використовуються при адресації в Асемблері. Тому за текстом програми вважають лише кількість констант, які свідомо поміщаються в одному байті. Як правило, вони виділяються в тексті і ймовірність їхнього збігу дуже мала. До значення цієї величини додають 256 - число можливих байтових констант. Для аналізованого ПЗ зазначені величини мають такі значення:

82 + 334 + 280 + 256 = 952.

Отримані значення можна порівняти з розрахунковими значеннями, які визначені з вирішення рівнянь Холстеда для

В результаті рішення Ці значення можна вважати прийнятними (на відміну від реального ПЗ становить 11,0% та 10,5%).

Розрахуємо довжину програми

та визначимо обсяг програми

Уточнена оцінка переданої кількості помилок у ПЗ дорівнює:

Оцінка відрізняється від отриманої раніше = 168 лише на 12% і за своїм змістом є ближчою до реальності.

2.3.3 Методика розрахунку інтенсивності виявлення помилок залежно від часу експлуатації програми

У процесі комплексної налагодження ПЗ видозмінюється з метою здійснення функцій і внесення виправлень для виявлених помилок у вже реалізованій програмі. Такі зміни зазвичай заносяться до спеціального журналу обліку виправлень із зазначенням дати та семантики виправлення. Як приклад розглянемо з прикладу 1. Вихідними даними є результати комплексної налагодження цього ПЗ приблизно за дворічний період. Кількість виявлених помилок фіксувалося щомісячно, тому інтенсивність виявлення помилок має розмір «кількість помилок/місяць». Значення інтенсивності виявлення помилок за 20 місяців наведено нижче у таблиці. Таблиця 2.3 – Значення інтенсивності виявлення помилок

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

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

Таблиця 2.4 – Інтенсивність виявлення помилок на квартал уперед

2.3.4 Статистична оцінка ймовірності безвідмовної роботи

програмного забезпечення

Розглянемо метод послідовного аналізу з метою оцінки ймовірності безвідмовної роботи програми. У ньому вводиться припущення про те, що якщо ймовірність успішного прогону Рзнаходиться в досить малій околиці точки Р 0, то ризик ухвалення неправильного рішення допустимо малий. Під неправильним рішенням розуміють рішення відкинути надійну програму або пропустити надійну програму. Для формалізації цього припущення ставлять такі P`і P`` (P`

Що прийняття не надійної програми розглядається як помилкове рішення тільки при , а відмова від надійної програми є помилковим у разі, коли . Після завдання значень ймовірностей P`і P``допустимий ризик прийняття неправильних рішень такий, що можливість помилки першого роду, тобто. відмовитися від надійної програми, має перевищувати α = Вер , а ймовірність помилки другого роду, тобто. прийняття не надійної програми має перевищувати β = Вер . Значення величин і при цьому призначаються, виходячи з розумного компромісу, до початку випробувань, так як з їх зменшенням зростає обсяг випробувань.

Сутність послідовного аналізу гіпотези Н 0 (Р = Р 0)полягає у перевірці двох конкуруючих гіпотез Н`(P = P`)і H``(P = P``).Тут під ймовірністю безвідмовної роботи ПЗ P(m)розуміють ймовірність отримання вибірки в якій для елементів P`

Тоді

Якщо вірна гіпотеза H`, то

Аналогічно, якщо вірна гіпотеза H``, то

Складемо відношення «правдоподібності»:

(2.114)

Послідовний аналіз проводиться доти, доки виконуватиметься такі нерівності:

(2.115)

Якщо на етапі m то ПЗ не надійно; а якщо то ПЗ можна прийняти як надійне.

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

Елементи програмного забезпечення не старіють через знос чи втому;

У апаратурі використання стандартних елементів поширене набагато ширше, ніж у системі програмного забезпечення;

Кількість документації з програмного забезпечення набагато більша порівняно з кількістю документації для апаратних засобів;

Ввести зміни до програм просто, але важко зробити це коректно.

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

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

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

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

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

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

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

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

Помилки, приховані у самій програмі;

Спотворення вхідної інформації, що підлягає обробці;

Неправильні дії користувача;

Несправності апаратури, де реалізується обчислювальний процес.

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

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

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

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

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

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

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

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

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

Функція надійності P(t), яка визначається як ймовірність того, що помилка програми не виявиться на інтервалі від 0 до t, тобто. час її безвідмовної роботи буде більшим за t;

Функція ненадійності Q(t) - ймовірність того, що протягом часу t відбудеться відмова програми внаслідок прояву помилки у програмі;

Інтенсивність відмов - умовна щільність ймовірності часу до виникнення відмови програми за умови, що на момент t відмови був;

Середнє напрацювання - математичне очікування тимчасового інтервалу між послідовними відмовими.

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

Експоненційна модель надійності ґрунтується на припущенні про експоненційний характер зміни в часі числа помилок у програмі.

У цій моделі прогнозується надійність програми з урахуванням даних, отриманих під час тестування. У моделі вводиться сумарний час функціонування, який відраховується від початку тестування програми (з усуненням виявлених помилок) до контрольного моменту, коли проводиться оцінка надійності. Тестування інформаційної підсистеми проводиться протягом місяця (= 168 год.).

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

Якщо M – число помилок, що є у програмі перед фазою тестування (M = 10); m() - кінцеве число виправлених помилок, а m 0 () - число помилок, що залишилися, тоді

m 0 () = M - m() (4.4)

За прийнятих припущень інтенсивність відмов пропорційна m 0 (), тобто.

де C - коефіцієнт пропорційності, що враховує реальну швидкодію системи та кількість команд у програмі.

Перед початком роботи системи (t = 0) жодна помилка не була виправлена ​​(= 0), тому

Характеризуватимемо надійність програми після тестування протягом часу середнім часом напрацювання на відмову:

Отже,

Введемо - вихідне значення середнього часу напрацювання на відмову перед тестуванням (= 1000 год.). Тоді

В результаті маємо

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

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

В інформаційній системі використовується випробувана апаратура, що пройшла тривале тестування;

На тестування інформаційної системи відведено недостатній час отримання достовірних даних.

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

На ринку програмних комплексів (ПК) представлено низку зарубіжних та вітчизняних ПК, що дозволяють проводити автоматизований розрахунок надійності складних технічних систем, у тому числі радіоелектронної апаратури (РЕА) та електрорадіовиробів (ЕРІ).

Найбільш поширеними серед зарубіжних ПК є: RELEX (Relex software Corporation, США); A.L.D.Group (Ізраїль); Risk Spectrum (Relcon AB, Швеція); ISOGRAPH (Велика Британія).

Серед вітчизняних ПК, що застосовуються на низці підприємств: ПК АСОНІКА-К (МІЕМ-ASKsoft); ПК АСМ (ПК для автоматизованого структурно-логічного моделювання та розрахунку надійності та безпеки систем, ВАТ «СПІК СЗМА»); ПК «Універсал» (для розрахунків надійності та функціональної безпеки технічних пристроїв та систем, ФГУП «ВНДІ УП МПС РФ»); ІМК КОК (інструментально-моделюючий комплекс для оцінки якості функціонування інформаційних систем, ФГУП «3 ЦНДІ МО РФ») та ін. Для розрахунку надійності РЕА та ЕРІ також широко використовують автоматизовану довідково-інформаційну систему (АСРН) (ФГУП «22 ЦНДІІ МО РФ» ), автоматизовану систему розрахунку надійності ЕРІ та РЕА (АСРН-2000, ВАТ «РНДІ "ЕЛЕКТРОНСТАНДАРТ"»), АСРН-1 (для ЕРІ та РЕА народногосподарського призначення, ВАТ «РНДІ "ЕЛЕКТРОНСТАНДАРТ"»).

Розглянемо найпопулярніші зарубіжні та вітчизняні ПК з погляду їх використання для розрахунку надійності РЕА.

ПК Relex та Risk Spectrum

ПК Relex та Risk Spectrum дозволяють проводити логіко-імовірнісний аналіз надійності та безпеки технічних систем, наприклад, розрахунок надійності сучасних автоматизованих систем управління технологічними процесами (АСУТП), оптимізацію техногенного ризику та визначення оптимальних параметрів системи технічного обслуговування потенційно небезпечних об'єктів. Основне застосування ПК Risk Spectrum отримав у ймовірнісному аналізі безпеки об'єктів атомної енергетики на стадії проектування. Комплекс Spectrum використовується більш ніж на 50% атомних станцій світу, включений до переліку програмних засобів, атестованих Радою з атестації програмних засобів Держатомнагляду Росії у 2003 р. ПК Relex та Risk Spectrum можуть бути використані для розрахунку надійності не тільки керуючих чи технологічних систем, а й виробів приладобудування, обчислювальної техніки, на транспорті, оборонної техніки.

В основі моделювання та розрахунку показників надійності та безпеки технічних систем, що широко застосовуються в Європі та США, лежать логіко-імовірнісні методи, що використовують як засіб побудови графічних моделей безпеки (надійності) дерева подій (ДС) та дерева відмов (ДО) рис. 1 та 2.

Мал. 1. а) Модель надійності (безпеки), представлена ​​за допомогою дерева відмов та подій; б) дерево відмов у ПК Relex

Мал. 2. а) дерево подій у редакторі ДС; б) дерево відмов у редакторі ДО ПК Risk Spectrum

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

Якщо можна стверджувати, що система працездатна у разі працездатності її елементів A та B, то можна зробити висновок про те, що працездатність системи (подія С) та працездатність елементів A та B (подія A та подія B) пов'язані між собою логічним рівнянням працездатності: C = AB. Тут позначення використовується для відображення логічної операції І. Логічне рівняння працездатності цього випадку може бути представлено схемою послідовного з'єднання елементів A і B.

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

Таблиця. Зразковий список вершин та подій у ПК Relex

У модулі ДО ПК Relex використовуються логіко-динамічні оператори (вершини), що враховують залежність подій, часові співвідношення, пріоритети (рис. 1б). Він дозволяє здійснювати розрахунок наступних показників: можливість відмови; неготовність; параметр потоку відмов; середня кількість відмов. Значення показників обчислюються як для вершинної події, так кожного проміжного. Для кожної виділеної події можна переглядати та аналізувати набори відповідних мінімальних перерізів.

У ПК Risk Spectrum ДС представляється у вигляді таблиці, що містить рядок заголовків, поле, в якому вміщено розімкнений бінарний граф (дерево подій), кілька стовпців з характеристиками кінцевих станів об'єкта, що моделюється, що реалізуються в процесі здійснення аварійних послідовностей (рис. 2а). У заголовку 1-го стовпця таблиці вказується позначення вихідних подій. У наступних заголовках стовпців зліва направо розміщуються назви та умовні позначення проміжних подій, що відповідають успішному або неуспішному виконанню функцій безпеки, працездатним чи відмовним станам систем безпеки або окремих компонентів (обладнання та технічних засобів), правильним чи хибним діям персоналу. У стовпцях, що характеризують кінцеві стани (КС), вказуються їх номери, умовні позначення, типи (наприклад, КС із пошкодженням активної зони), ймовірність реалізації, логічні формули, що відповідають даним аварійним послідовностям (АП).

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

З ПК Relex (Relex Software Continental Europe GmbH, www.relex.com) працюють багато відомих зарубіжних фірм, таких як LG, Boeng, Motorolla, Dell, Cessna, Siemens, Raytheon, HP, Honda, Samsung, Cisco Systems, Nokia, EADS, 3M, NASA, Intel, GM, Kodak, AT & T, Philips, Pirelli, Quallcomm, Seagete, Emerson.

До складу ПК Relex reliability studio 2007 входять різні аналітичні модулі для вирішення широкого спектру завдань: прогнозування безвідмовності (Reliability Prediction); ремонтопридатності (Maintainability Prediction); аналізу видів, наслідків та критичності відмов (FMEA/FMECA); марковського аналізу (Markov Analysis), статистичного аналізу (Weibull Analysis); оцінки вартості терміну служби обладнання (Life Cycle Cost); а також блок-схеми надійності (Reliability Block Diagram); дерева відмов/подій (Fault Tree/Event Tree); система оповіщення про відмови, аналіз та коригувальні дії, FRACAS-система (Failure Reporting Analysis and Corrective Action System); система оцінки людського фактора та аналізу ризиків (Human Factors, Risk Analysis).

Модуль прогнозування безвідмовності містить моделі розрахунку показників надійності елементів. У нього включена велика база даних, що містить класифікаційні ознаки елементів та характеристики надійності. Розрахунки проводяться відповідно до стандартів: MIL-HDBK-217, Telcordia (Bellcore), TR-332, Prism, NSWC-98/LE1, CNET93, HRD5, GJB299.

Модуль аналізу ремонтопридатності реалізує положення стандарту дослідження ремонтопридатності систем - MIL-HDBK-472. Вирішуються завдання прогнозування профілактики технічного обслуговування.

Модуль аналізу видів, наслідків та критичності відмов відповідає стандартам MIL-STD-1629, SAE ARP 5580 та ін. Проводиться ранжування небезпечних відмов та їх оцінка за пріоритетами ризиків.

Модуль блок-схем надійності (RBD, Reliability Block Diagram) використовується для аналізу складних резервованих систем. Містить як аналітичні методи, і методи моделювання Монте-Карло.

Модуль дерева відмов/дерева подій дозволяє реалізовувати процедури для дедуктивного та індуктивного аналізу розвитку відмов, подій у системі. Застосовується для аналізу надійності та безпеки. Містить широкий набір логіко-функціональних вершин.

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

У модулі ПК Relex Markov реалізовані марківські процеси з дискретним безліччю станів та безперервним часом, що враховують такі особливості функціонування та резервування систем: несумісні види відмов елементів; послідовність виникнення відмов; зміна інтенсивностей відмов елементів залежно від подій, що вже відбулися (зокрема, ступінь навантаженості резерву); кількість бригад з відновлення (обмежена/необмежена); черговість відновлення; обмеження на ЗІП; різну ефективність функціонування в різних станах системи та доходи (втрати) за переходи до стану. Обчислювані показники: ймовірність кожного із станів; ймовірність безвідмовної роботи (відмови) на заданому інтервалі часу та ін.

Модуль статистичного аналізу "Weibull" призначений для обробки результатів випробувань, експлуатації. Для опису катастрофічних відмов на ванноподібній кривій інтенсивності відмов широко використовують нормальне, логнормальне розподілу, розподіл Вейбулла та ін. складної технічної системи Логнормальний та вейбулівський розподіл однаково добре описують відмови, характерні для періоду старіння.

Модуль статистичного аналізу «Weibull» використовує різні види розподілів, включаючи нормальний, Вейбулла, логнормальний, рівномірний, експоненціальний, Гумбеля, Релея, біноміальний та ін. Подання та аналіз даних для обраних класів параметричних розподілів проводиться з використанням методу «імовірнісного паперу». На ній аналізований розподіл є прямою лінією, що забезпечує наочність і дозволяє природним чином застосовувати всі методи регресійного аналізу, зокрема, перевірку адекватності моделі та значущості коефіцієнтів регресії (фішеровський аналіз). Для оцінок параметрів розподілів пропонується великий набір методів, наприклад, методи Хазена (Hazen), Бенарда (Benard) та їх модифікації, біномне оцінювання, метод середніх величин, метод максимальної правдоподібності та його модифікація та ін.

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

ПК АСМ

Найбільш відомим із вітчизняних ПК є програмний комплекс автоматизованого структурно-логічного моделювання (ПК АСМ). Теоретичною основою є загальний логіко-імовірнісний метод системного аналізу, що реалізує всі можливості основного апарату моделювання алгебри логіки в базі операцій "І", "АБО", "НЕ". Форма уявлення вихідної структури системи – схема функціональної цілісності, що дозволяє відображати практично всі відомі види структурних моделей систем. Комплекс автоматично формує розрахункові аналітичні моделі надійності та безпеки систем та обчислює ймовірність безвідмовної роботи, середнє напрацювання до відмови, коефіцієнт готовності, середнє напрацювання на відмову, середній час відновлення, ймовірність відмови відновлюваної системи, ймовірність готовності змішаної системи, а також значущість та внесок елементів у різні показники надійності системи загалом. ПК АСМ дозволяє також автоматично визначати найкоротші шляхи успішного функціонування, мінімальні перерізи відмов та їх комбінації.

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

ПК A.L.D. Group

Фірма A.L.D. Group (Ізраїль-США, http://www.aldservice.com/) об'єднує дві компанії, що спеціалізуються в галузі логістики (logistics information system) та оцінки надійності: SoHaR та FavoWeb (http://www.favoweb.com/).

Програмний продукт FavoWeb - це працююча в Інтернеті динамічна FRACAS-система (Failure Reporting Analysis and Corrective Action System - Система оповіщення про відмови, аналіз та коригувальні дії). Багато закордонних компаній, наприклад компанія Lockheed Martin, широко використовують систему FRACAS.

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

Система FRACAS дозволяє створювати бази даних, переводячи різнорідні дані структуровану інформацію про якість. Має потужний механізм дій, що коригують: підтримка роботи груп аналізу відмов/дефектів/матеріалів, аналіз глибинних причин відмов, усунення проблем. Містить модуль Workflow для автоматизації повідомлення про відмови та серійні номери.

Програма пропонує широкий набір функцій, можливостей оцінки та покращення надійності обладнання завдяки тісній інтеграції із системою аналізу RAM Commander (рис. 3). Крім того, FavoWeb включає спеціальні можливості щодо внесення та обліку змін, логістики та відстеження серійних номерів виробів (CALS-технології).

Мал. 3. Вікно системи аналізу надійності RAM Commander

Під терміном CALS-технології (Continuous Acquisition and Lifecycle Support) розуміється сукупність принципів та технологій інформаційної підтримки життєвого циклу виробу всіх його стадіях. Російськомовний аналог CALS – інформаційна підтримка життєвого циклу виробів (ІПІ). Останнім часом за кордоном поряд із CALS використовується також термін Product Lifecycle Management (PLM). Важливим аспектом CALS-технологій є інформаційна підтримка безпосередньо процесу оцінки надійності технічної системи. RAM Commander дозволяє обчислювати середнє напрацювання на відмову/критичний відмова (MTBF/ MTBCF), середній час на ремонт (MTTR), середній час між усуненнями відмов (MTBMA) та ін.

Базова конфігурація FavoWeb дозволяє створювати звіти (розподіл дефектів/відмов та перелік відмов/дефектів за заданими користувачем параметрами); проводити коригувальні дії; будувати дерево продукту; працювати з різними бібліотеками/довідниками; має модуль адміністратора.

На рис. 3 наведено вікно системи аналізу надійності RAM Commander, яка охоплює весь спектр інженерних завдань, пов'язаних із надійністю електронних, електромеханічних, механічних та інших систем. Вона дозволяє прогнозувати надійність, готовність та ремонтопридатність різного роду обладнання, пропорційний розподіл між надійністю та ремонтопридатністю; управляти даними по надійності, готовності та ремонтопридатності; проводити аналіз надійності проектованого обладнання методом Монте-Карло; оптимізувати складський облік запасних частин.

На рис. 3 показаний приклад розрахунку надійності РЕА. Об'єкт складається з приймально-передавального компонента (Communic), компонента управління (Control) та монтажної шафи (Pedestal). Комутуюча частина приймально-передаючого компонента - радіоелектронні та механічні компоненти: ІВ, резистори, конденсатори, фотоприймачі, перемикач. Елементи проектованої системи, що мають найвищу інтенсивність відмов, позначені червоним кольором, наприклад блок живлення (PS), що має експлуатаційну інтенсивність відмов 8350 ФІТ та інтенсивність відмов у режимі очікування 700 ФІТ. Другий за величиною вклад вносить монтажну шафу (Pedestal), що складається з антени, механічного мотора та опори (виділені жовтим кольором).

На рис. 4 показано редагування надійних характеристик КМОП ІВ типу 74HC04 у різних режимах експлуатації проектованої РЕА: в операційному (робочому) режимі, в режимі зберігання (очікування). Передбачається, що ІС використовуватиметься в РЕА, призначеній для наземних стаціонарних умов експлуатації (умовне позначення режиму - GF, температура експлуатації - 49,3 °C, градієнт температури - Delta Temp 4,3 °C). При заданому режимі експлуатації для ІС типу 74HC04 прогнозована інтенсивність відмов за довідником передбачення надійності Telecordia Issue 1 становитиме FRp ≈ 32 ФІТ (1 ФІТ = 10 –4 %/1000 год = 10 –9 1/год). Використовуючи довідник Telcordia, також можна редагувати конструктивно-технологічні характеристики ІС. Наприклад, з довідника витягуємо інформацію, що ІВ типу 74НС04 представляє популярне сімейство логічних швидкодіючих КМОП схем (вітчизняний аналог – серія КР1564). Число вентилів – 6, корпус – герметичний. Інтенсивність відмов ІС 74HC04 може бути передбачена й з використанням інших зарубіжних регламентуючих документів (довідників): - Chinese Standard, IRPH93 - Italtel, ALCATEL, RADC 85-91, NPRD-95, NSWC-98. На рис. 5а показана діаграма Парето, що дозволяє визначити частку інтенсивності відмов складових частин проектованої РЕА загальної інтенсивності відмов. Також показано залежність інтенсивності відмов РЕА від температури (рис. 5б) та середній час напрацювання на відмову (рис. 5в).

Можливості RBD-модуля розрахунку структурної надійності RAM Commander багато схожі з RBD-модулем ПК Relex. Проте можливості останнього значно ширші, оскільки він дозволяє враховувати такі чинники: вид резервування (постійне, заміщення, ковзне); ймовірність та час успішного підключення резерву; навантаженість резерву; механізм прояву відмови; різні стратегії відновлення; наявність ЗІП, профілактичного обслуговування та технічних оглядів.

RBD-модуль ПК Relex вирішує оптимальні завдання надійності: визначення числа резервних елементів, що максимізує показники надійності/продуктивності або мінімізує вартість системи; визначення оптимальних періодів профілактичного обслуговування чи технічних оглядів. Результатом його є обчислення наступних показників: ймовірності безвідмовної роботи; середнього напрацювання до відмови; інтенсивність відмов системи; коефіцієнта готовності (стаціонарний/нестаціонарний); параметра потоку відмов; середньої кількості відмов; середнього напрацювання на відмову.

Використовуючи RBD-модуль RAM Commander, можна побудувати різні варіанти (функціонально-надійні схеми) з послідовним, паралельним і послідовно-паралельним (K out of N) з'єднанням компонентів проектованої системи, а також провести аналіз надійності варіанта блок-схеми з використанням статистичного аналізу за методом Монте-Карло. Модуль дозволяє задавати індивідуально для кожного блоку: розподіл інтенсивностей відмов - експоненційне, нормальне, логнормальне, Вейбулла, Ерланга та ін; середній час напрацювання між відмовами (MTBF, год); навантаженість робочого циклу у %; вказувати ступінь ремонтопридатності (повністю або частково) і задавати імовірнісні розподіли та їх параметри для блоків, що ремонтуються (наприклад, для експоненційного розподілу вказується час знаходження блоку в ремонті). На рис. 6 показані оцінки ймовірності безвідмовної роботи для двох функціонально-надійнісних схем, побудовані в припущенні, що відмови компонентів проектованого об'єкта протягом 100 тис. год експлуатації підпорядковуються експоненційному розподілу, при цьому всі компоненти, що відмовили, повністю ремонтопридатні.

На вітчизняному ринку представлена ​​підсистема АСОНІКА-К, що успішно розвивається (на думку розробників АСОНІКА-К переросте в програмний комплекс, тому надалі називатимемо її ПК АСОНІКА-К) - програмний засіб вирішення завдань аналізу та забезпечення надійності в рамках автоматизованого проектування РЕА (рис. 7). За своїми можливостями підсистема АСОНІКА-К не поступається модулям RBD зарубіжних ПК A.L.D. Group (RAM Commander), Relex, Isograph та ін. Її використання є кращим, так як АСОНІКА-К дозволяє вести розрахунок надійності РЕА, що виробляється в Росії, на основі даних, наведених у вітчизняних довідниках «Надійність електрорадіовиробів», «Надійність електрорадіовиробів зарубіжних». аналогів». Відповідає вимогам комплексу військових стандартів «Мороз-6» для РЕА відповідального застосування та стандарту США MIL-HDBK-217 та стандарту КНР GJB/z 299B.

Мал. 7. ПК АСОНІКА-К. Система розрахунку надійності СЧ: а) приклад розрахунку надійності РЕА; б) приклад графічного аналізу залежності інтенсивності відмов від температури навколишнього середовища

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

БД клієнтської частини ПК містить інформацію про проектовану РЕА. Така організація клієнтської частини дозволяє проводити розрахунки РЕА паралельно з кількома робочими станціями. Клієнтська частина програми має графічний постпроцесор та інтерфейси із системами моделювання фізичних процесів та конструкторського проектування, у тому числі АСОНІКА-Т, P-CAD 2001, АСОНІКА-М та ін. Математичне ядро ​​ПК містить в якості моделі надійності експоненціальне та DN-розподілення та може бути адаптоване до будь-якої іншої моделі надійності. Воно дозволяє розраховувати РЕА, що містять чотири ієрархічних рівнів розукрупнення і мають різні типи резервування. Результати розрахунків можуть бути як у текстовому, і у графічному вигляді.

ПК АСОНІКА-К дозволяє проводити наступні види аналізу розрахунку надійності (СРН, аналог RBD-модуля RAM Commander, Relex RBD, Isograph RBD): аналіз результатів розрахунків надійності РЕА, СРН яких є довільним з'єднанням складових частин (деревоподібне, ієрархічне і т.д. .) та аналіз результатів розрахунку складових частин, з послідовним з'єднанням.

На рис. 7а наведено приклад розрахунку надійності РЕА з використанням ПК АСОНІКА-К. Показано складові РЕА (щит живлення, блок живлення і т. д.), а також результат розрахунку надійних характеристик об'єкта: ймовірність безвідмовної роботи, експлуатаційна інтенсивність відмов, середній час напрацювання до відмови та внесок елементів у загальну інтенсивність відмов. З іншого боку, на рис. 7б наведено приклад графічного аналізу залежності інтенсивності відмов від температури навколишнього середовища.

Використання ПК АСОНІКА-К дозволяє підвищувати надійність РЕА шляхом резервування її складових частин (рис. 8). На рис. 8 показані групи К01-К08, виділені з об'єкта, значення ймовірності безвідмовної роботи, коефіцієнт готовності та коефіцієнт оперативної готовності всього об'єкта в цілому.

Відмови складових частин є раптовими і є незалежними подіями, час до відмови є випадковою величиною, розподіленою за експоненційним законом з постійною інтенсивністю відмов λ. На рис. 9 показано функцію та щільність розподілу часу напрацювання на відмову, а також залежність інтенсивності відмов проектованої РЕА з використанням графічного аналізу.

ПК дозволяє проводити розрахунок надійності з використанням різних видів резервування складових частин: ковзне гаряче резервування, гаряче резервування та без резервування, а також забезпечує способи контролю їх працездатності (безперервний/періодичний). На рис. 10 наведено фрагменти файлів звіту ПК АСОНІКА-К, а саме: розрахунок надійності складових частин (рис. 10а), розрахунок надійності складного виробу (рис. 10б), які формуються у форматі html.

Перспективою розвитку ПК є розробка ще двох модулів: системи обліку впливу на характеристики надійності зовнішніх факторів (рис. 11) та інформаційно-довідкову систему за характеристиками надійності сучасної елементної компонентної бази (ЕКБ) (рис. 12).

Мал. 11. ПК АСОНІКА-К. Система аналізу та обліку впливу на надійність зовнішніх факторів

Мал. 12. ПК АСОНІКА-К. Інформаційно-довідкова система з характеристик надійності сучасної ЕКБ

Резюме

ПК Relex, Risk Spectrum та АСМ реалізують клас моделей оцінки показників надійності технічних систем – логіко-ймовірнісного моделювання. Його можна назвати класом статистичних моделей, оскільки вони дозволяють обчислювати показники надійності, безпеки та ефективності систем у довільний момент часу, залежно від можливих наборів працездатних та непрацездатних станів елементів системи.

Окремі модулі ПК A.L.D. Group (RAM Commander), Relex, Isograph можна використовувати для автоматизованого розрахунку надійності вітчизняної РЕА тільки на основі імпортних ЕРІ (або їх вітчизняних аналогів), оцінка надійності яких ведеться за різними зарубіжними довідниками. Використання зарубіжних ПК вимагає від користувачів високої підготовки в галузі математичної статистики та її застосування до завдань теорії надійності.

ПК АСОНІКА-К не поступається можливостями зарубіжним ПК і може бути рекомендований щодо розрахунків надійності вітчизняної РЕА з урахуванням як імпортних, і вітчизняних ЭРИ. Головна перевага – можливість вести розрахунки надійності, використовуючи вітчизняні довідники «Надійність електрорадіовиробів» та відповідати вимогам комплексу військових стандартів «Мороз-6» для РЕА відповідального застосування. Реалізація сучасної концепції CALS-технологій забезпечує безперервну інформаційну підтримку, пов'язану з експлуатаційними відмови вітчизняних ЕРІ.

Література

1. http://www.axoft.ru
2. ChipNews. Новини EDA Expert. 2002. № 10.
3. Сайт компанії Електрейд-М. www.eltm.ru
4. http://www.favoweb.com/
5. http://www.riskspectrum.com
6. http://www.isograph.com
7. EDA Expert_6_52_55.pdf. Жаднов Ст, Жаднов І., Замараєв С. та ін. Нові можливості програмного комплексу АСОНІКА-К
8. ПК АСМ. Методи оцінки надійності, безпеки та ризику. http://www.szma.ru
9. Управління якістю під час проектування теплонавантажених радіоелектронних засобів: Навчальний посібник / Жаднов В. В., Сарафонов А. В. М.: «Солон-прес», 2004.

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

Найбільш розроблений апарат оцінки характеристик надійності спирається на модель надійності Джелінського-Моранди, яка буде розглянута нижче.

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

Розглянута модель заснована на таких припущеннях:

час до наступної відмови розподілено експонентно;

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

Згідно з цими припущеннями ймовірність безвідмовної роботи програм як функція часу t iдорівнює:

P(t i )=exp(-l i × t i ) , (1)

де l i = З × (N-(i-1)). (2)

Тут З- Коефіцієнт пропорційності;

N- Початкова кількість помилок програми.

У виразі (1) відлік часу t iпочинається від моменту останнього (i-1) відмови програми, а значення l iзмінюється під час прогнозування різних відмов.

Значення C і Nу виразі (2) визначаються за експериментально зафіксованими інтервалами часу Dt iміж моментами виникнення відмов у процесі налагодження програми На основі методики максимуму правдоподібності значення Nодержують як рішення нелінійного рівняння:

де До- Число експериментально отриманих інтервалів між відмовими.

Реальне значення Nотримують методом підбору, ґрунтуючись на тому, що це ціле число.

Значення коефіцієнта пропорційності Зотримують як:

. (4)

Ця методика працює для К³2, тобто. треба мати хоча б два експериментально отримані інтервали між моментами виникнення помилок.

Приклад прогнозування відмов програмного забезпечення

Нехай під час налагодження програми зафіксовано інтервали часу Dt 1 =10, Dt 2 =20, Dt 3 =25 між відмовами програми. Значення Dtможуть визначатися в одиницях часу, а можуть – серед прогонів програми при тестуванні. Визначимо можливість працездатності програми P(t 4 )= exp(- l 4 × t 4 ) , тобто. відсутності наступної, четвертої відмови, починаючи з моменту усунення третьої відмови та середній час Т 4 до наступної відмови програми.

Вирішуємо рівняння (3) щодо Nшляхом перебору.

Для N=4 маємо при К=3

Для N=5

Найменшу помилку забезпечує N=4 , звідки відповідно до виразу (4):

.

Таким чином ймовірність безвідмовної роботи у відсутності 4-ї відмови складає

P(t 4 )= exp(-0,02 × t 4 ) , а T 4 =1/ l 4 =50 .

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

прикладрозрахунку зіркоподібної мережі:

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

Розрахунок надійності ЛОМ починають із формування поняття відмови цієї мережі. Для цього аналізуються управлінські функції, виконання яких на підприємстві здійснюється з використанням цієї ЛОМ. Вибираються такі функції, порушення яких неприпустимо, та визначається обладнання ЛОМ, задіяне при їх виконанні. Наприклад: безперечно, протягом робочого дня повинна забезпечуватися можливість виклику/запису інформації з бази даних, а також звернення до Інтернету.

Для сукупності таких функцій за структурною електричною схемою визначається обладнання ЛОМ, відмова якого безпосередньо порушує хоча б одну із зазначених функцій, і складається логічна схема розрахунку надійності.

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

Відновлення обмежене – тобто. будь-якої миті часу неспроможна відновлюватися більше, ніж один елемент, що відмовив, т.к. є одна ремонтна бригада;

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

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

Встановимо як критерій відмови ЛОМ відмову обладнання, що входить в ядро ​​мережі: серверів, комутаторів або кабельного обладнання.

Вважаємо, що відмова робочих станцій користувачів не призводить до відмови ЛОМ, а оскільки одночасна відмова всіх робочих станцій – подія малоймовірна, мережа при окремих відмови робочих станцій продовжує функціонувати.

Надійність зіркоподібної мережі.

Відмова не впливає на відмову всієї мережі. Надійність ЛОМ визначається надійністю центрального вузла.

Приймемо, що локальна мережа включає один сервер, два комутатори і чотирнадцять кабельних фрагментів, що відносяться до ядра мережі. Інтенсивність відмов та відновлень для них наведені нижче, як і раніше, К Г =1-l/m.

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

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

Підсистема серверів:

l З = 2 * l 1 = 2 * 10 -5; До ГС = 1-2 * 10 -4; m С = =0,1 1/год.

Підсистема комутаторів:

l до = 2 * 10 -5; До Гк = 1-2 * 10 -3; m до =
1/год.

Підсистема кабелів:

l л = 14 * 10 -6; К Гл = 1-14 * 10 -6; m л = 1 1 / год.

Для всієї мережі:

l s = 6,5 * 10 -5; К Г s = 1-2,4 * 10 -3; ms = 0,027 1 / год.

Результат розрахунку:

Т=15 тис. год., К Р =0,998, Т В»37 год.

Розрахунок вартості ЛОМ:

14 мережевих карток: 1500руб.

Кабель 1км: 2000руб.

Рознімання: 200руб.

Сервер: 50тис. руб.

Усього: 2 53700 т. руб.