Функціональна безпека, Частина 3 із 3. МЕК 61508: Систематична випадковість чи випадкова систематичність?

Безпеки на Хабре присвячений цілий хаб, і, мабуть, ніхто особливо не замислюється, що саме вкладається в поняття «безпека», і так все ясно: інформаційна безпека (security). Однак, є ще й інша сторона безпеки, safety, пов'язана з ризиками для здоров'я і життя людей, а також навколишнього середовища. Оскільки інформаційні технології самі по собі небезпеки не представляють, то зазвичай говорять про функціональної складової, тобто про безпеку, пов'язану з правильним функціонуванням комп'ютерної системи. Якщо інформаційна безпека стала критична з появою інтернету, то функціональна безпека розглядалася і до появи цифрового управління, адже аварії відбувалися завжди.

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

У вступної частини 1:

— обґрунтовано важливість оцінювання та забезпечення функціональної безпеки для комп'ютерних систем управління;
— розглянуто архітектури систем, для яких необхідно оцінювати і забезпечувати функціональну безпеку; до таких систем відносяться АСУ ТП (Industrial Control Systems) на базі програмованих логічних контролерів (ПЛК), вбудовані системи (Embedded Systems) і рівень пристроїв (Device Layer) для інтернету речей;
— коротко представлено безліч стандартів, що відносяться до функціональної безпеки в різних сферах застосування.

У частині 2 розглянута загальна структура стандарту МЕК 61508 «Функціональна безпека систем електричних, електронних, програмованих електронних, пов'язаних з безпекою» (IEC 61508 Functional safety of electrical/electronic/electronic programmable safety-related systems) і використовувана в ньому термінологія.

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

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

Як розібратися в структурі вимог МЕК 61508?

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


Малюнок 1. Overall framework of the IEC 61508 series (IEC 61508, Figure 1)

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

Дійсно, частини МЕК 61508-1,2,3 мають типове зміст, оскільки у всіх трьох частинах:

— у розділі 5 викладено вимоги до документації;
— у розділі 6 наведено вимоги до управління функціональної безпекою;
— у розділі 7 описана структура життєвого циклу;
— у розділі 8 викладено вимоги до оцінювання функціональної безпеки.

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

1) випадкові відмови апаратних засобів, для яких можна визначити ймовірність виникнення;
2) систематичні відмови викликані помилками проектування.

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

— управління функціональної безпекою (Functional Safety Management);
— реалізацію життєвого циклу функціональної безпеки (Functional Safety Life Cycle);
— захист від систематичних відмов проектування системи і апаратних засобів (Systematic Failures Avoidance);
— захист від систематичних відмов проектування програмного забезпечення (Software Failures Avoidance).

Крім того, необхідно виконувати оцінку функціональної безпеки (Functional Safety Assessment) шляхом визначення відповідності продуктів (обладнання, програмного забезпечення і документації) і процесів розробки продуктів зазначеним вище вимогам.

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


Малюнок 2. Структура вимог МЕК 61508

МЕК 61508-1, Загальні вимоги
Перша частина, МЕК 61508-1, задає тон всьому стандарту. Деяка складність для розуміння полягає в тому, що ця частина в чому описує рівень об'єкта контролю і управління, не дуже звичний для IT-фахівців. Тут підхід навіть ширше, ніж рівень АСУ ТП, і набагато ширше, ніж рівень контролера і софта. Що з цим робити? Вибирати тільки ті вимоги, які відносяться безпосередньо до розроблюваної або оцінюваної системи.


Малюнок 3. Зміст МЕК 61508-1

Тут і далі на Mind Map розділи і додатки розмічені знизу ярликами, які вказують на те, до якої групи вимог відповідає той чи інший розділ або додаток. Крім того, на Mind Map створена гілка Important, підкреслює важливі таблиці та рисунки, які без цього «губляться» в тексті стандарту.

Вимоги до документації (розділ 5) віднесемо до групи Functional Safety Management. МЕК 61508-1 містить ще й додаток А, що належить до документації, але воно, на мій погляд, не особливо корисно. Рекомендовану структуру документації (виходячи з досвіду сертифікації) розглянемо в наступних публікаціях. Структура документів багато в чому визначає і структуру життєвого циклу, а він у нас, як і для всіх програм, пов'язаних з безпекою – V-подібний.

МЕК 61508-2, Вимоги до систем
Друга частина, МЕК 61508-2, як випливає з назви, належить до керуючої системи. Як було визначено у вступній публікації з функціональної безпеки, ми розглядаємо три типи архітектур керуючих систем: вбудовані системи (Embedded Systems), АСУ ТП на базі ПЛК (Industrial Control Systems) і Device Layer інтернету речей. Важливо відзначити, що, крім системних вимог, МЕК 61508-2 визначає також вимоги до апаратної (hardware) складової систем. Розділи 5, 6 та 8 містять лише посилання на МЕК 61508-1.


Малюнок 4. Зміст МЕК 61508-2

У складі МЕК 61508-2 ми знайдемо ряд важливих програм, які носять нормативний характер, тобто обов'язковий до виконання характер:

— у додатку А запропонований підхід до реалізації самодіагностики, а також до захисту від систематичних відмов;
— у програмі заходів захисту від систематичних відмов доповнені вимогами до їх реалізації на різних етапах життєвого циклу системи;
— у програмі показано, як розраховувати діагностичне покриття в цілях забезпечення того або іншого рівня повноти безпеки (SIL);
— у додатку D сформульовані вимоги до змісту посібника, яке з урахуванням вимог до безпеки носить назву Safety Manual;
— в додаток Е описані підходи до внутрикристальному резервування при реалізації керуючих функцій з використанням інтегральних схем;
— додаток F формально є інформативним, тобто як би необов'язковим до виконання, але, тим не менше, де-факто його треба розглядати, якщо в системах застосовуються замовні інтегральні схеми (ASIC) або програмовані логічні інтегральні схеми (FPGA & CPLD).

МЕК 61508-3, Вимоги до програмного забезпечення
Третя частина, МЕК 61508-3, визначає вимоги до програмного забезпечення, яке може бути, як компонентом системи, так і окремим об'єктом оцінювання і сертифікації.


Малюнок 5. Зміст МЕК 61508-3

Розділи 5, 6 та 8 традиційно посилаються на МЕК 61508 1, але є невеликі доповнення, які враховують особливості програмного забезпечення.

З додатків важливі А і В, що містять вимоги до захисту від відмов програмного забезпечення. У додатку D містяться вимоги до керівництва по експлуатації (Safety Manual) в частині особливостей.

МЕК 61508-4, Терміни і визначення
МЕК 61508-4 містить структурований перелік використовуваних термінів, що детально розглянуто в частина 2 публікації.


Малюнок 6. Зміст МЕК 61508-4

МЕК 61508-5, Рекомендації щодо застосування методів визначення рівнів повноти безпеки
МЕК 61508-5 наводить досить абстрактні приклади того, як визначати рівень повноти безпеки (safety integrity level, SIL). Я б розглядав цю частину просто, як ілюстративний матеріал для вивчення, тим більше, що, коли ми отримуємо вихідні дані для розробки системи чи, то рівень повноти безпеки (SIL), як правило, там уже заданий.



Малюнок 7. Зміст МЕК 61508-5

МЕК 61508-6, Керівництво по застосуванню МЕК 61508-2 і МЕК 61508-3
МЕК 61508-6 голосно заявляє про те, що він містить настанови щодо застосування частин 2 і 3 МЕК 61508, тобто вимог до системи, апаратного та програмного забезпечення. Насправді, в додатку А міститься досить тривіальне опис етапів виконання проекту (на рівні «розробіть вимоги», «сплануйте роботу» і т. д.). Що дійсно представляє інтерес, так це докладні приклади розрахунку показників надійності і безпеки (додатка B, C, D), а також приклад того, як впроваджувати методи забезпечення повноти безпеки (safety integrity) для програмного забезпечення (додаток Е). Останнім ілюструє застосування додатків А і В з МЕК 61508-3.


Малюнок 8. Зміст МЕК 61508-6

МЕК 61508-7, Методи і засоби
МЕК 61508-7 містить перелік методів захисту від випадкових відмов апаратних засобів і від систематичних помилок проектування (як системи і апаратних засобів, так і програмного забезпечення). Схоже, що автори стандарту постаралися опублікувати все, що вони коли-небудь чули про ці методи. Тому, там багато теоретичних речей, які навряд чи можуть бути ефективно застосовані на практиці. Тим не менш, застосування основних підходів в частині діагностування, тестування, організації управління проектом і т. п. є обов'язковими нормативними вимогами. Таким чином, вивчати МЕК 61508-7 слід на основі МЕК 61508-2 і МЕК 61508-3, де як раз і описаний прагматичний підхід до впровадження захисту від відмов і помилок.


Малюнок 9. Зміст МЕК 61508-7

Висновки
Розгляд МЕК 61508 на основі класифікації та структуризації вимог дозволило розкласти «по поличках» цей серйозний документ із семи частин і 700 сторінок.
Класифікаційні ознаки вимог дозволяють виділити аспекти функціональної безпеки, які треба буде розглянути для повноти картини у планованому циклі статей, а саме:

— оцінювання ймовірності випадкових відмов і забезпечення захисту від таких відмов (Random Capability) через призму теорії надійності і безпеки;
— управління функціональної безпекою (Functional Safety Management) й оцінювання функціональної безпеки (Functional Safety Assessment);
— реалізацію життєвого циклу функціональної безпеки (Functional Safety Life Cycle), включаючи тестування;
— методи захисту від систематичних відмов проектування системи і апаратних засобів (Systematic Failures Avoidance) і від систематичних відмов проектування програмного забезпечення (Software Failures Avoidance).

Нагадаю, що у першій вступній частині публікації:

— обґрунтовано важливість оцінювання та забезпечення функціональної безпеки для комп'ютерних систем управління;
— розглянуто архітектури систем, для яких необхідно оцінювати і забезпечувати функціональну безпеку; до таких систем відносяться АСУ ТП (Industrial Control Systems) на базі програмованих логічних контролерів (ПЛК), вбудовані системи (Embedded Systems) і рівень пристроїв (Device Layer) для інтернету речей;
— коротко представлено безліч стандартів, що відносяться до функціональної безпеки в різних сферах застосування.

У другій частині публікації: розглянута загальна структура стандарту МЕК 61508 «Функціональна безпека систем електричних, електронних, програмованих електронних, пов'язаних з безпекою» (IEC 61508 Functional safety of electrical/electronic/electronic programmable safety-related systems) і використовувана в ньому термінологія.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.