Реферат: Соу-н нкау 0060: 2010

СОУ-Н НКАУ 0060:2010




НАСТАНОВА НАЦІОНАЛЬНОГО КОСМІЧНОГО АГЕНТСТВА УКРАЇНИ






Галузева система управління якістю


ГАРАНТОЗДАТНІСТЬ ПРОГРАМНО-ТЕХНІЧНИХ КОМПЛЕКСІВ
КРИТИЧНОГО ПРИЗНАЧЕННЯ


Всього сторінок 60


НКАУ

ПЕРЕДМОВА

1 РОЗРОБЛЕНО: Харківський госпрозрахунковий підрозділ ”Сертифікаційний Центр АСУ” державного підприємства “Державний центр регулювання якості поставок та послуг”

РОЗРОБНИКИ:^ Ю. Алексеє^




Галузева система управління якістю


ГАРАНТОЗДАТНІСТЬ ПРОГРАМНО-ТЕХНІЧНИХ КОМПЛЕКСІВ
^ КРИТИЧНОГО ПРИЗНАЧЕННЯ


Отраслевая система управления качеством

ГАРАНТОСПОСОБНОСТЬ ПРОГРАММНО-ТЕХНИЧЕСКИХ

КОМПЛЕКСОВ КРИТИЧЕСКОГО НАЗНАЧЕНИЯ





Чинна від 01.04.2010
^ 1 СФЕРА ЗАСТОСУВАННЯ
1.1 Ця настанова установлює поняття, терміни і визначення щодо гарантоздатності, структуру і зв’язки меж її складових, а також вимоги до гарантоздатності програмно-технічних комплексів критичного призначення.

Ця настанова доповнює вимоги та положення ДСТУ 2850, Правил космічної діяльності в Україні УРКТ-01.01, СОУ-Н НКАУ 0012,
^ СОУ-Н НКАУ 0031, СОУ-Н НКАУ 0058.

1.2 Ця настанова призначена для застосування підприємствами, науково-дослідними інститутами, організаціями, установами (далі – підприємствами), що знаходяться у сфері управління Національного космічного агентства України (НКАУ), незалежно від форм власності та видів діяльності, під час розроблення та виготовлення космічної техніки.

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

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

^ 2 НОРМАТИВНІ ПОСИЛАННЯ
У цій настанові є посилання на такі нормативні документи:

ГОСТ 2700-89. Надежность в технике. Термины и определения (Надійність техніки. Терміни та визначення). – М.: Издательство стандартов

ДСТУ 2850-94 Програмні засоби ЕОМ. Показники і методи оцінювання якості

ДСТУ 2860-94. Надійність техніки. Основні терміни та визначення. – К.: Держстандарт України

ДСТУ 3918-1999 (ISO/IEC 12207:1995) Процеси життєвого циклу програмного забезпечення

ДСТУ 3919-1999 (ISO/IEC 14102:1995) Основні напрямки оцінювання та відбору CASE-інструментів

ДСТУ ISO 9000:2007 Основні положення та словник термінів

ДСТУ ISO/IEC 14764:2002 Інформаційні технології: Супроводження програмного забезпечення

ДСТУ ISO/IEC 3524:1997 Надiйнiсть техніки. Проектна оцінка надійності складних систем з урахуванням технічного і програмного забезпечення та оперативного персоналу

ДСТУ ISO/IEC 2382-14:2005 Системи оброблення інформації. Безвідмовність, обслуговування та готовність

УРКТ-01.01 Правила космічної діяльності в Україні. Розробка, виготовлення та експлуатація ракетно-космічної техніки

СОУ-Н НКАУ 0012:2006 Галузева система управління якістю. Вимоги до якості програмного забезпечення програмно-технічних комплексів критичного призначення

СОУ-Н НКАУ 0031:2007 Галузева система управління якістю. Методи оцінки показників якості програмного забезпечення програмно-технічних комплексів критичного призначення

СОУ-Н НКАУ 0058:2008 Галузева система управління якістю. Вимоги до функціональної безпеки програмного забезпечення програмно-технічних комплексів критичного призначення.
^ 3 ТЕРМІНИ ТА ВИЗНАЧЕННЯ ПОНЯТЬ
Нижче подано терміни, вжиті у цій настанові, та визначення позначених ними понять. Іншомовні відповідники подано англійською мовою.

3.1 безвідмовність (reliability)

Властивість безперервно надавати коректні (необхідні) послуги впродовж заданого часу (напрацювання)

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

Здатність програмного продукту досягати прийнятних рівнів ризику шкоди людям, бізнесу, програмному забезпеченню (ПЗ), майну або навколишньому середовищу в заданому контексті використання [1]

3.3 вимірювання

Процес визначення кількісного або якісного (категорійного) значення атрибутів об'єкта оцінювання [2]

^ 3.4 відмова програмного забезпечення (software failure)

Подія, пов’язана з частковим або повним невиконанням функцій ПЗ відповідно до специфікації, яка виникає внаслідок використання програм або даних з дефектом і призводить або може призвести до відмови системи [3]

3.5 відмовобезпека (fault-safety)

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

^ 3.6 відмовобезпечна система (fault-safe system)

Система, в якій забезпечується відмовобезпека

3.7 відмовостійкість (fault-tolerance)

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

^ 3.8 відмовостійка система (fault-tolerant system)

Система, в якій забезпечується відмовостійкість

3.9 вірогідність (high confidence)

Властивість правильно оцінювати коректність даних і наданих послуг

3.10 гарантоздатність (dependability)

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

3.11 готовність (availability)

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

^ 3.12 дефект програмного забезпечення (software fault)

Вплив помилки (невідповідність специфікації) у програмі або даних комп’ютера, який призводить до неадекватного виконання програми, якщо ПЗ використовувало цей сегмент програм або даних [3]

3.13 живучість (survivability)

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

^ 3.14 життєвий цикл системи

Весь період існування системи від початку розроблення до завершення її використання (ДСТУ 3918)

3.15 залишковий ризик (residual risk)

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

^ 3.16 категорія критичності програмного забезпечення

Ступінь значимості функцій, що виконує ПЗ для забезпечення безпеки
космічної техніки [4]

3.17 конфіденційність (confidentiality)

Властивість перешкоджати неавторизованому доступу до інформації обмеженого доступу

^ 3.18 критичне програмне забезпечення (safety critical software)

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

Наприклад, програмне забезпечення, яке:

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

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

– безпосередньо виконує управління і контроль за умовами або станом апаратних компонентів, і його невиконання, непослідовне виконання або виконання, пов’язане з помилками персоналу, апаратною відмовою чи відмовою внаслідок впливу навколишнього середовища може спричинити небезпеку або може призвести до існування умов виникнення ризиків [5]

^ 3.19 критичний об'єкт (critical item)

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

3.20 надійність (dependability)

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


^ 3.21 надійність програмного забезпечення

Сукупність властивостей, що обумовлюють здатність програмного продукту зберігати зазначений рівень працездатності у заданих умовах [1]

^ 3.22 об’єкт космічної техніки (об’єкт космічної діяльності)

Матеріальний предмет штучного походження, що проектується, виготовляється та експлуатується як у космічному просторі (космічний сегмент, космічна інфраструктура), так і на поверхні Землі (наземний сегмент, наземна інфраструктура) з метою дослідження та використання космічного простору (УРКТ-01.01)

3.23 обслуговуваність (maintainability)

Властивість пристосованості до модифікацій, обслуговування та ремонту

^ 3.24 оцінювання якості програмного забезпечення

Систематичне перевіряння того, наскільки об'єкт здатний виконувати встановлені вимоги (ДСТУ 2860)

3.25 показники (характеристики) якості програмного забезпечення

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

3.26 помилка (error)

Розбіжність між обчисленим, спостереженим або виміряним значенням чи умовою та істиною, або теоретично правильним значенням чи умовою

^ 3.27 програмний продукт (software product)

Набір комп'ютерних програм, процедур і пов'язаних з ними документації та даних (ДСТУ 3918)

3.28 програмно-технічний комплекс

Сукупність технічних засобів автоматизації, що поставляються у комплекті з програмним забезпеченням, необхідним сервісним устаткованням та експлуатаційною документацією, що з’єднуються на місці експлуатації з периферійним устаткованням та/або іншими програмно-технічними комплексами для виконання усіх або частини функцій контролю та управління у складі конкретної інформаційної або керуючої системи [6]

3.29 процес (process)

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

Примітка 1. Входами одного процесу є зазвичай виходи з інших процесів.

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

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

(ДСТУ ISO 9000)

^ 3.30 процес забезпечення якості

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

3.31 ризик (risk)

Кількісна характеристика потенційних втрат, а також імовірність несення втрат

^ 3.32 система критичного застосування

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

3.33 таксономія (taxonomy)

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

^ 3.34 функціональна безпека програмного забезпечення (software functional safety)

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

3.35 характеристика (characteristic)

Характерна особливість.

Примітка 1. Характеристика може бути власною чи наданою.

Примітка 2. Характеристика може бути якісною або кількісною.

Примітка 3. Існують різні класи характеристик, зокрема:

– фізичні (наприклад, механічні, електричні, хімічні чи біологічні характеристики);

– органолептичні (наприклад, пов’язані із запахом, дотиком, смаком, зором, слухом);

– етичні (наприклад, увічливість, чесність, правдивість);

– часові (наприклад, пунктуальність, безвідмовність, доступність);

– ергономічні (наприклад, характеристики фізіологічні чи пов’язані з безпекою людини);

– функційні (наприклад, максимальна швидкість літака)

(ДСТУ ISO 9000)

^ 3.36 характеристика якості (quality characteristic)

Власна характеристика продукції, процесу або системи, пов’язана з вимогою.

Примітка 1. «Власний» означає наявність у чому-небудь саме як постійна характеристика.

Примітка 2. Надані характеристики продукції, процесу чи системи (наприклад, ціна продукції, власник продукції) не є характеристиками якості цієї продукції, процесу чи системи.

3.37 цілісність (integrity)

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

^ 3.38 якість програмного забезпечення

Сукупність властивостей ПЗ, які обумовлюють його придатність задовольняти певні потреби відповідно до призначення (ДСТУ 2850).

^ 4 ПОЗНАКИ ТА СКОРОЧЕННЯ
У цій настанові застосовано такі скорочення:

АЕС

–

атомні електричні станції

АМР

–

адаптивне мажоритарне резервування

ДВ

–

дефекти взаємодії

ДP

–

дефекти розроблення або проектування

ДФ

–

дефекти фізичні

ІТС

–

інформаційно-технічний стан

ІКС

–

інформаційно-керуюча система

КС

–

космічна система

НБС

–

непрацездатний безпечний стан

НІТС

–

непрацездатний інформаційно-технічний стан

НС

–

небезпечний стан

НТС

–

непрацездатний технічний стан

ОКУ

–

об’єкт контролю та управління

ПЗ

–

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

ПК

–

підсистема контролю

ПНС

–

повністю непрацездатний стан

ПС

–

працездатний стан

ПТК

–

програмно-технічний комплекс

ПТК КП

–

програмно-технічний комплекс критичного призначення

ПУ

–

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

ССБ

–

структурна схема безпеки

ССЖ

–

структурна схема живучості

ССН

–

структурна схема надійності

ЧП

–

частково працездатний стан
^ 5 ГАРАНТОЗДАТНІСТЬ ПРОГРАМНО-ТЕХНІЧНИХ КОМПЛЕКСІВ КРИТИЧНОГО ПРИЗНАЧЕННЯ
5.1 Таксономічна схема гарантоздатності

5.1.1 Гарантоздатність та її складові влвстивості

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

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

Гарантоздатність включає:

– безвідмовність (reliability) – властивість надавати коректні (необхідні) послуги впродовж заданого часу;

– готовність (availability) – властивість доступності ресурсів для надання необхідних послуг;

– обслуговуваність (maintainability) – властивість пристосовуватись до модифікацій, обслуговування та ремонту;

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

– функціональна безпека (safety) – властивість виключати або мінімізувати шкідливі (включаючи катастрофічні) наслідки у разі відмов для користувачів, інших систем або навколишнього середовища;

– цілісність (integrity) – властивість виключати непередбачені зміни даних, системи та надаваних послуг;

–конфіденційність (confidentiality) – властивість перешкоджати неавторизованому доступу до інформації обмеженого доступу;

– вірогідність (high confidence, trustworthiness) – властивість правильно оцінювати коректність наданих послуг, тобто визначати ступінь довіри до послуги.

^ 5.1.2 Первинні та вторинні властивості. Взаємозв’язок властивостей

5.1.2.1 Таксономічну схему гарантоздатності наведено на рис. 5.1. Схема включає:

– властивості, що складають гарантоздатність. Властивості, що складають гарантоздатність відповідно до 5.1.1.2, є первинними;

– загрози (дефекти, помилки, вразливості, втручання, відмови тощо), що призводять до порушення працездатності;

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

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

– зв’язки між цими поняттями.

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

5.1.2.3 Потрібно ураховувати такі особливості таксономічної схеми (рис. 5.1) та її елементів:

– у визначенні гарантоздатності обов'язковим є термін «необхідні», тобто специфіковані послуги (функції), оскільки без цього розмиваються межі властивості;

– включення властивостей конфіденційності, живучості та вірогідності як складових гарантоздатності залежить від призначення і специфіки використання КС;





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

– якщо дозволено деградацію (зниження) обсягу та якості послуг, що надаються, живучість для таких КС повинна розглядатися як частина гарантоздатності;

– до первинних властивостей гарантоздатності доцільно включити вірогідність, тому що її ознакою є необхідність «…оправдано довіряти» послугам, що надаються (та функціям, що виконуються) (5.1.1.2);

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

– властивість «готовність» не розглядалася в ДСТУ 2860 та міжнародних стандартах як первинна властивість надійності та могла в їхніх рамках представлятися як сукупність властивостей безвідмовності і ремонтопридатності;

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

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


^ 5.2 Інформаційно-технічний стан

5.2.1 Дефекти та уразливості, що призводять до порушення працездатності

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

Множину дефектів, які класифікують за ознаками, поділяють на три групи:

– дефекти розроблення або проектування (ДP) (development or design faults);

– фізичні дефекти (ДФ) (physical faults);

– дефекти зовнішніх впливів (взаємодій) (ДВ) (interaction faults).

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

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

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

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

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

^ 5.2.2 Множина технічних станів програмно-технічного комплексу

5.2.2.1 ПТК, у загальному випадку, може мати: (рис. 5.2) множину працездатних (безпечних) станів МSПС, множину частково працездатних (і безпечних) станів МSіЧП, (d – число допустимих рівнів деградації) і множину повністю непрацездатних станів МSПНС. Якщо d > 1, розглянута система має властивість живучості.

До складу МSПНС входять множини: непрацездатних безпечних станів МSНБС і небезпечних станів МSНС. При цьому, множину МSНС розглядають як множину функціонально небезпечних (аварійних) станів, а множини МSНБС і МSЧП поєднують функціонально безпечні стани.

Інформаційна безпека може забезпечуватися частково для множин МSЧП. З урахуванням можливих типів відмов через ДР, ДФ і ДВ система з вихідного справного стану S0 переходить у стани (підмножини станів) SДР, SДФ і SДВ відповідно. Якщо ці дефекти виникають, але не виявляються, система переходить у стани (підмножини станів) S'ДР, S'ДФ і S'ДВ.

5.2.2.2 За умов виявлення дефектів та їхнього парирування (усунення) система переходить у справний стан S0 у випадку, якщо це не пов'язано із включенням резервних ресурсів (апаратних, програмних) або використанням ресурсів, які не поповнюються (не можуть поповнюватися за умовами функціонування), і в такий спосіб залишається у просторі станів множини МSПС1. Ця множина може включати й інші стани, наприклад, пов'язані із профілактикою, відновленням ПТК тощо (на рис. 5.2 не наведено).




Можливий перехід системи зі станів множини МSПС1 у стани множини МSПСj, , викликаний зменшенням запасу ресурсів за умови збереження у повному обсязі її функціональності. У випадку поповнення ресурсів можливий зворотний перехід.

За умови неможливості збереження повної функціональності системи (рівня основних характеристик) після виникнення нових дефектів ДР, ДФ або ДВ відбувається перехід у стани з множини MSіЧП. Структура простору станів цієї множини аналогічна структурі МSПС.

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

^ 5.2.3 Поняття про інформаційно-технічний стан

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

Множина станів (справних – несправних, працездатних – частково працездатних – непрацездатних, безпечних – потенційно небезпечних –небезпечних або критичних) повинна розглядатися з урахуванням того, що переходи між ними можуть здійснюватися внаслідок не тільки виникнення або прояву ДР, ДФ, але й внаслідок дефектів взаємодії (interaction faults) ДВ, викликаних випадковими ненавмисними й навмисними зовнішніми впливами фізичної природи (механічними, електромагнітними, радіаційними) та інформаційними впливами (помилковими діями персоналу, хакерськими атаками, спамом тощо).

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

Таким чином, ІТС – це сукупність властивостей та ознак як технічного, так і інформаційного характеру, про придатність системи у певний момент часу. Ця сукупність є більш розвинутою, ніж технічний стан, і повинна визначати критерії класифікації станів комп'ютерної (інформаційно-керуючої) системи з урахуванням моделі (рис. 5.2).

При цьому в ІТС реалізується у повному обсязі принцип доповнення – один з важливих принципів теорії систем, відповідно до якого стани ПТК та ІКС в цілому повинні розглядатися з урахуванням взаємодії із зовнішнім середовищем. Якщо внаслідок порушення конфіденційності зовнішня система одержала несанкціонований доступ до «внутрішньої» інформації ПТК, це повинно кваліфікуватися як перехід цієї системи в несправний (непрацездатний, небезпечний) інформаційно-технічний стан, а відповідна подія – як ушкодження, збій або відмова (часткова, повна небезпечна або безпечна).

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

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

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


^ 5.2.4 Зміна інформаційно-технічних станів

5.2.4.1 Система може перебувати в одному з восьми інформаційно-технічних станів, кількість яких визначається комбінацією трьох типів дефектів – ДФ, ДР, ДВ. Кожному стану і відповідній вершині графу станів (рис. 5.3) надають трирозрядний код ДФ, ДР, ДВ, який описує наявність відповідних дефектів (1 – дефект присутній, 0 – відсутній). Переходи на графі, на яких виникають два або три дефекти різних типів, показані пунктиром як менш імовірні.


SНТС

Рисунок 5.3 – Граф ІТС


5.2.4.2 Наявність (виникнення) ДФ призводить до непрацездатного технічного стану SНТС (100), а прояв ДР або виникнення ДВ – до непрацездатного інформаційного стану SНІТС (010, 001, 011).

Якщо стан системи характеризується порушенням справності як за технічною, так і інформаційної складовою, його кваліфікують як несправний (непрацездатний, небезпечний) інформаційно-технічний стан SНІТС. У множину SНІТС входять підмножини SНІТС1(101), SНІТС2(110), SНІТС3(111), залежно від комбінації дефектів ДР і ДВ, за наявності ДФ.


^ 5.3 Методи забезпечення гарантоздатності

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

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

а) прогнозування (fault forecasting, Ff) можливості появи (прояву) дефекту і виникнення відмови внаслідок цього дефекту;

б) попередження (fault prevention, Fp) появи (прояву) дефекту і виникнення відмови;

в) виявлення (fault detection, Fd) появи (прояву) дефекту, помилки обчислень, відмови;

г) ідентифікації (fault diagnosis, Fi) причини, виду і місця дефекту (відмови);

д) парирування (fault tolerance Ft) наслідків дефекту і виникнення відмови. Ця остатня дія включає:

1) відключення (fault isolation, Fs) елементів (компонентів, модулів архітектури), які відмовили, і/або ізолювання перекрученої інформації;

2) реконфігурацію (fault removal, Fr) структури (архітектури) шляхом видалення компонента, який відмовив, з конфігурації та заміни його працездатним; реконфігурація може проводитися і для групи компонентів залежно від особливостей системи та відповідних засобів реконфігурування;

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

5.3.1.2 У таблиці 5.1 наведено певну відповідність між складовими (властивостями) гарантоздатності та операціями відмовостійкості (символом «+» позначено операції (засоби) відмовостійкості, які виконуються (вводяться в дію) для забезпечення відповідної властивості).

Таблиця 5.1 – Матриця відповідності властивостей гарантоздатності та операцій відмовостійкості

Складові
властивості

гарантоздатності

Операції (функції) відмовостійкості




Ff, прогно-зування

Fp, попере-дження

Fd, вияв-лення

Fi,

іденти-фікація

Ft, пари-рування

Fs,

від-клю-чення

Fr, реконфі-гурація

Fc, віднов-лення

Безвідмовність







+




+










Готовність







+

+




+




+

Обслуговуваність

+

+

+

+







+




Вірогідність







+

+













Функціональна безпека

+

+

+




+

+

+




Живучість

+

+

+

+

+

+

+

+

Цілісність

+

+

+




+

+




+

Конфіденційність

+

+

+




+











Операції, наведені у таблиці 5.1, утворюють у часі цикл забезпечення відмовостійкості F та повинні виконуватися за послідовно-паралельною схемою (рис. 5.4), деякі елементи якої можуть бути або відсутні, або реалізовуватися сумісно у часі.

Ff


Fp

Fd

Fi

Ft

Fr








Fc



Fs


F




Рисунок 5.4 –Діаграма операцій відмовостійкості


5.3.1.3 Кожен з методів забезпечення відмовостійкості повинен бути проаналізований, виходячи з наявності та особливостей реалізації елементів множини MF = {Ff, Fp, Fd, Fi, Ft, Fs,Fr, Fc}.

У таблиці 5.2 наведено звичайне мажоритарне резервування «два з трьох» («2 з 3»), яке забезпечує відмовостійкість тільки за допомогою операції Ft; адаптивне мажоритарне резервування (АМР) – за допомогою операцій Fd (виявлення факту відмови другого каналу), Fi (ідентифікації працездатного каналу), Ft (парирування наслідків відмови першого, а потім і другого каналу), Fr (реконфігурації структури з мажоритарної – в одноканальну конфігурацію), FS(відновлення елементів після відмови), Fc (відновлення обчислювального процесу).

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


Таблиця 5.2 – Співвідношення методів забезпечення та операцій відмово стійкості



Методи

забезпечення відмовостійкості

Операції

відмовостійкості


Ff


Fp

Fd

Fi

Ft

Fs

Fr

Fc

Мажоритарне

резервування

«2 з 3»

-

-

-

-

+

-

-

-

Адаптивне мажоритарне резервування

(перехід від «2 з 3» до «1 з 1»)

-

-

+

+

+

+

+

±

Адаптивне мажоритарне резервування

з рейтингуванням каналів

+

±

+

±

+

±

±

±
5.3.2 Відмовобезпека як механізм забезпечення функціональної безпеки

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

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

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

5.3.2.3 Стійкість до відмов, причинами яких є дефекти взаємодії, включає стійкість до випадкових або спрямованих фізичних впливів та стійкість до інформаційних втручань. Стійкості до зовнішніх інформаційних втручань (вторгнень) відповідає англомовний термін “intrusion tolerance” , а системам, у яких реалізується така стійкість – термін “intrusion tolerant system”. Це є відображенням не тільки автономності, але й важливості властивості інформаційної безпеки (і живучості) у складі гарантоздатності.

5.3.3 Принцип диверсності та багатоверсійні технології

5.3.3.1 З огляду на різну природу дефектів ДР, ДФ, ДВ і наслідків викликаних ними відмов, засоби, які реалізують операції з множиною MF, для них можуть бути роздільними. ПТК у цьому випадку повинен мати три підсистеми, які виконують функції Fi  MF для кожного з типів дефектів WFДФ, WFДР і WFДВ відповідно (рис. 5.5, а)). Інтегрованими повинні бути засоби реалізації функції відновлення інформації WFС.

Роздільна реалізація підсистем призводить до більших витрат програмно-апаратних засобів, які роблять підсисте