Функціональна безпека, Частина 2 з 2. МЕК 61508: ким бути, Шерлоком Холмсом чи Дата Туташхиа?


Джерело

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

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

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

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

Вивчення стандартів і закладеної в них термінології – це не саме веселе заняття в світі, але, при прагматичному підході, технічний рівень спеціаліста може від цього підвищитися. Тлумачення термінології є свого роду «технічної юриспруденцією», а хитросплетінню сюжетних ліній у викладі вимог може позаздрити будь-який автор детективу.
Я не стану запевняти, що, вивчаючи стандарти, всі відразу стануть технічними Шерлоками Холмсами. Хоча, знання основ стандартизації (тобто, технічного законодавства), лежить в основі роботи будь-якого сищика технічного експерта. Вивчення стандартів – це скоріше шлях Дата Туташхиа з напівзабутого нині романа Чабу Амирэджиби (а є ще екранізація – «Берега»), шлях не стільки вперед, скільки в глибину, не стільки в дію, скільки на осмислення.

Загальні відомості про МЕК 61508
Стандарт оперує терміном електрична/ електронна/ програмована електронна (е/Е/ПЕ) система (electrical/electronic/electronic programmable).

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

Наприклад, звернемо увагу на системи захисту атомних реакторів. Для них в режимі постійної роботи відмови повинні відбуватися не частіше, ніж один раз в 1000 років експлуатації (10 мільйонів годин напрацювання на відмову). Такі показники задаються не для одиничного об'єкта, а для «флоту», тобто для безлічі однотипних об'єктів. Начебто, відмови є досить рідкісними подіями, адже жодна атомна електростанція не пропрацює тисячу років. Однак, якщо врахувати, що в світі експлуатується більше 400 атомних реакторів, то для «флоту» ми вже отримаємо цифру один відмова в 2,5 року, що звучить набагато більш гнітюче. Під час Чорнобильської та Фукусімській ядерних катастроф системи аварійного захисту не спрацювали так, як очікувалося проектувальниками. Це ще один аргумент на користь важливості розгляду функціональної безпеки.

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

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

Перша редакція МЕК 61508 була розроблена з 1998 по 2000 роки. У Російській Федерації перша редакція була прийнята в якості державного стандарту ГОСТ Р МЕК 61508 в 2007 році. В даний час у світі діє друга редакція МЕК 61508, випущена в 2010. У Російській Федерації друга редакція МЕК 61508 також є актуальною з 2012 року (ГОСТ Р МЕК 61508-2012).

Серія стандартів МЕК 61508 включає 7 частин, які в сумі містять близько 600 сторінок тексту. Про призначення частин легко здогадатися з їх назв.



Звичайно, між частинами МЕК 61508 існують досить складні зв'язки, що відображено в малюнках самого стандарту: Overall framework of the IEC 61508 series (IEC 61508, Figure 1).



Термінологія МЕК 61508: базові терміни з безпеки
Для того, щоб розібратися з концепцією функціональної безпеки, мабуть, почати треба, не з початку і з кінця, а з середини, а саме з четвертої частини (МЕК 61508-4), де викладена основна термінологія. Як бачимо, терміни розділені на 8 груп (3.1-3.8). Ці групи логічно пов'язані між собою. На мій погляд, найважливішими є групи 3.1 (Safety terms) і 3.5 (Safety functions and safety integrity).



Далі терміни вибірково цитуються згідно російськомовного тексту МЕК 61508-4, а потім дається їх авторська інтерпретація.
Отже, перший розділ з термінології, 3.1 «Терміни, що відносяться до безпеки».

Дивитися терміни, що відносяться до безпеки»3.1.1 шкоди (harm): Фізичне пошкодження чи шкоду, заподіяну здоров'ю людей, майну або навколишньому середовищу.
3.1.2 небезпека (hazard): Потенційне джерело заподіяння шкоди
3.1.6 ризик (risk): Поєднання ймовірності події заподіяння шкоди P(t) та тяжкості цієї шкоди C.
3.1.7 допустимий ризик (tolerable risk) — Ризик, який прийнятний за даних обставин на підставі існуючих у суспільстві цінностей.
3.1.11 безпека (safety): Відсутність неприйнятного ризику.
3.1.12 функціональна безпека (functional safety): Частина загальної безпеки, обумовлена застосуванням керованого обладнання (УО) і системи управління УО, і залежить від правильності функціонування систем, пов'язаних з безпечністю, та інших засобів зниження ризику.
3.1.13 безпечний стан (safe state): Стан УО, в якому досягається безпека.

Я спробував пов'язати всі сутності в єдине ціле, і в результаті вийшла наступна схема (мабуть, можна назвати онтологією). Важливо відзначити, що комп'ютерна система управління (КСУ) є лише однією з багатьох заходів щодо зниження ризиків. Існує безліч так званих пасивних заходів захисту, наприклад, ремінь безпеки в автомобілі або літаку.



Ризик є показником безпеки, і на понятті ризику необхідно буде звернути увагу в подальшому, при розгляді цих самих показників. Поки наведу простий приклад. Ходить навіщо-то людина по краю даху. Імовірність падіння з даху при інших рівних умовах залежить від висоти будівлі. А от ступінь шкоди залежить. Тоді і ризик падіння з даху 10-поверхової будівлі буде вище, ніж ризик падіння з даху одноповерхової будівлі. А ось ризик падіння з даху 10-поверхової будівлі практично дорівнює ризику падіння з даху 100-поверхової будівлі, оскільки, якщо ймовірність падіння однакова, то і наслідки (шкоду) падіння тут, на жаль, також однакові.

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

Ще одним принциповим поняттям є «безпечний стан». Наприклад, одна з найважливіших систем безпеки, система протиаварійного захисту (ПАЗ), повинна зупинити функціонування керованого об'єкта. Як це відбувається? Як правило, шляхом розриву електричних ланцюгів (це вже залежить від технологічних алгоритмів керування обладнанням), що відбувається шляхом переказу вихідних дискретних сигналів в стан «логічний 0» (так званий принцип de-energize trip to, щоб система могла відпрацювати і при аварійної втрати електропостачання). При необхідності, «логічний 0» може бути інвертований в «логічну 1» через проміжні реле.

Термінологія МЕК 61508: терміни, що відносяться до функцій безпеки і повноті безпеки (safety integrity)
першої частини циклу статей я вже коротко згадував, що поняття функціональної безпеки включає в себе реалізуються функції безпеки і повноту (інтегрованість) виконання цих функцій.
В МЕК 61508-4, розділ 3.5 «Функції безпеки і повнота безпеки» наводяться відповідні терміни.

Дивитися терміни, що відносяться до функцій безпеки і повноті безпеки3.5.1 функція безпеки (safety function): Функція, реалізована е/Е/ПЕ системою, пов'язаної з безпекою, чи іншими заходами по зниженню ризику, призначена для досягнення або підтримання безпечного стану УО по відношенню до конкретної небезпечної події
3.5.4 повнота безпеки (safety integrity): Ймовірність того, що система, пов'язана з безпекою, буде задовільно виконувати необхідні функції безпеки при всіх обумовлених умовах протягом заданого інтервалу часу.
3.5.5 повнота безпеки програмного забезпечення (software safety integrity): Складова повноти безпеки системи, пов'язаної з безпекою, що стосується систематичних відмов, що проявляються в небезпечному режимі і належать до програмного забезпечення.
3.5.6 повнота безпеки, що стосується систематичних відмов (systematic safety integrity): Складова повноти безпеки системи, пов'язаної з безпекою, що стосується систематичних відмов, що проявляються в небезпечному режимі.
3.5.7 повнота безпеки апаратних засобів (hardware safety integrity): Складова повноти безпеки системи, пов'язаної з безпекою, що стосується випадкових відмов апаратури, що проявляються в небезпечному режимі.
3.5.8 рівень повноти безпеки; УПБ [safety integrity level (SIL)]: Дискретний рівень (приймає одне з чотирьох можливих значень), що відповідає діапазону значень повноти безпеки, при якому рівень повноти безпеки, рівний 4, є найвищим рівнем повноти безпеки, а рівень повноти безпеки, рівний 1, що відповідає найменшій повноті безпеки.
3.5.9 стійкість до систематичних відмов (systematic capability): Міра впевненості (виражена в діапазоні СЗГ 1 — ССО 4). що систематична повнота безпеки елементу відповідає вимогам заданого значення рівня повноти безпеки (УПБ) для певної функції безпеки елемента, якщо цей елемент застосований у відповідності з вказівками, визначеними для цього елемента у відповідному посібнику з безпеки.
3.5.16 режим роботи (mode of operation): Спосіб виконання функції безпеки або в режимі:
— з низькою частотою запитів (low demand mode), в якому функція безпеки виконується тільки за запитом і переводить УО в певний безпечний стан, а частота запитів не перевищує одного в рік або
— з високою частотою запитів (high demand mode), в якому функція безпеки виконується тільки за запитом і переводить УО в певний безпечний стан, а частота запитів перевищує один рік, або
— безперервному режимі (continuous mode), в якому функція безпеки підтримує УО в безпечному стані, як і при нормальному функціонуванні.

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

Ще одним центральним поняттям в МЕК 61508 є рівень повноти безпеки (Safety Integrity Level, SIL). Значення SIL встановлює в залежності від того, наскільки вплив керованого обладнання створює ризик для людей і навколишнього середовища.
Виходячи з цього, встановлено ризик відмови і для самої комп'ютерної системи управління. Наприклад, на початку статті я вже говорив, що для системи захисту атомного реактора напрацювання на відмову повинна становити не менш, ніж 10 мільйонів годин. Це відповідає SIL3. Взагалі, прийнято вважати, що SIL4 можуть відповідати лише найбільш прості пристрої. Для програмованих логічних контролерів (ПЛК), що використовуються в АСУ ТП, досяжним є SIL3.

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

Перша складова вимагає застосовувати заходи захисту від систематичних відмов, викликаних помилками проектування. Для цього необхідно вдосконалювати процеси проектування та розроблення, тестування, управління конфігурацією, проектного менеджменту і т. п. Це віддалено нагадує рівні Capability Maturity Model Integration (CMMI), але безпосередньо з ним не трасується. Для кожного із значень SIL визначений набір методів захисту від систематичних відмов, причому їх кількість і «суворість» зростає з підвищенням SIL.

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

Тут є цікавий фокус, який застосовують багато розробники ПЛК. Можна досягти рівня SIL2 при одноканальному конфігурації ПЛК. Тоді резервована конфігурація дасть SIL3. При цьому процеси розробки (systematic capability), повинні відповідати SIL3.

Тепер, за аналогією з попереднім розділом, спробуємо застосувати структуру оточення (небезпека, шкода, ризики, контмеры, кероване обладнання) для комп'ютерної системи управління (КСУ). Тут мова йде про небезпеку для виконання функцій безпеки КСУ, оскільки їх невиконання пов'язане з ризиком. Для зниження цього ризику застосовуються різні заходи по забезпеченню повноти безпеки. Як ми вже знаємо, ці заходи спрямовані на захист від випадкових і систематичних відмов.



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



Термінологія МЕК 61508: ще кілька корисних термінів
Отже, згідно МЕК 61508-4, у нас ще залишилося шість з восьми розділів по термінології.

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

Дивитися терміни, що відносяться до обладнання та устрйствам3.2.1 кероване обладнання; УО [equipment under control (EUС)]: Обладнання, машини, апарати чи установки, що використовуються для виробництва, обробки, транспортування, в медицині або в інших процесах.

В розділі 3.3 «Системи: загальні аспекти» також містити зрозумілі технарям визначення.

У розділі 3.4 «Системи: аспекти, пов'язані з безпекою» міститься важливе визначення, що відповідає на питання: «а що саме мається на увазі під системою, пов'язаної з безпекою?»

Дивитися терміни, що відносяться до аспектів, що пов'язані з безпекою3.4.1 система, пов'язана з безпекою (safety-related system) — Система, яка:
— реалізує необхідні функції безпеки, що вимагаються для досягнення і підтримки безпечного стану УО та
— призначена для досягнення своїми засобами або в поєднанні з іншими е/Е/ПЕ системами, пов'язаними з безпекою, та іншими засобами зниження ризику необхідної повноти безпеки для необхідних функцій безпеки.

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

Дивитися терміни, що відносяться до збоїв, відмов і помилок3.6.1 збій (fault): Ненормальний режим, який може викликати зниження або втрату здатності до функціонального блоку виконувати потрібну функцію.
3.6.4 відмова (failure): Припинення здібності функціонального блоку виконувати необхідну функцію або функціонування цього блоку будь-яким способом, відмінним від необхідного.
3.6.5 випадковий відмова апаратури (random hardware failure): Відмова, що виникає у випадковий момент часу, який є результатом одного або декількох можливих механізмів погіршення характеристик апаратних засобів.
3.6.6 систематична відмова (systematic failure): Відмова, пов'язаний детермінованим чином з певною причиною, яка може бути виключений тільки шляхом модифікації проекту, або виробничого процесу, операцій, документації, або інших факторів.
3.6.7 небезпечний відмова (dangerous failure): Відмова елементів і/або підсистем і/або системи, які приймають участь в реалізації функцій безпеки, у результаті чого:
а) функція безпеки не виконується, коли це потрібно (для режимів з низькою або високою частотою запитів) або відмовляє (для безперервного режиму), що призводить до перекладу УО в небезпечне або потенційно небезпечний стан;
б) знижується ймовірність того, що функція безпеки при необхідності коректно буде виконана.
3.6.8 безпечний відмова (safe failure): Відмова елементів і/або підсистем і/або системи, які приймають участь в реалізації функцій безпеки, у результаті чого:
а) призводять до виконання функції безпеки з перекладу УО (або його частини) у безпечний стан або підтримують безпечний стан;
б) збільшується ймовірність виконання функції безпеки з перекладу УО (або його частини) у безпечний стан або підтримки безпечного стану.
3.6.10 відмова з загальною причиною (common cause failure): Відмова, який є результатів одного або кількох подій, що викликали одночасні відмови двох або більше окремих каналів у багатоканальній системі, що ведуть до відмови системи.
3.6.11 помилка (error): Розбіжність між обчисленим, спостережуваними або виміряним значенням або умовою і правильним, заданих або теоретично правильним значенням або умовою.

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

Дивитися терміни, що відносяться до процесів життєвого циклу3.7.1 життєвий цикл систем безпеки (safety lifecycle): Необхідні процеси, що відносяться до реалізації систем, пов'язаних з безпекою, проходять протягом періоду часу, починаючи зі стадії розробки концепції проекту і закінчуючи стадією, коли всі е/Е/ПЕ системи, пов'язані з безпекою, та інші засоби зниження ризику вже не використовуються.

У розділі 3.8 «Підтвердження заходів по забезпеченню безпеки» інтерес становлять визначення, що даються для верифікації та валідації. Відразу скажу, що зазвичай у життєвому циклі валідація та верифікація (verification and validation, V&V) розглядається як єдиний процес. Безпосередньо під валідацією розуміються випробування повністю інтегрованої системи з фізичної симуляцією вхідних і вихідних сигналів, а під верифікацією – всі інші огляди, аналізи і тести. Але з визначень МЕК 61508 цього зовсім не випливає.

Дивитися терміни, що відносяться до підтвердження заходів по забезпеченню безпеки3.8.1 верифікація (verification) — Підтвердження виконання вимог шляхом дослідження та збору об'єктивних свідчень.
3.8.2 підтвердження відповідності (validation): Підтвердження, шляхом випробувань та подання об'єктивних свідчень, виконання конкретних вимог до передбаченого конкретного використання.

Висновки
МЕК 61508 являє собою досить розлогий, складний, часом заплутаний і суперечливий стандарт, що включає в себе 7 частин. «Розплутати» його можна, тільки застосовуючи на практиці.

В основі МЕК 61508 лежить ризик-орієнтований підхід. Рівні ризику для комп'ютерних систем управління призначаються в залежності від впливу керованого техногенного об'єкта на навколишнє середовище, а також на здоров'я і життя людей.
Для цього в МЕК 61508 введено поняття рівня повноти безпеки (Safety Integrity Level, SIL), які встановлені по висхідній, від 1 до 4. Для відповідності того чи іншого SIL необхідно реалізувати заходи по захисту від випадкових відмов апаратних засобів, а також від систематичних відмов, викликаних помилками проектування. Тому, для кожного з SIL задані вимоги до продукту у вигляді значень показників безпеки та вимоги до «строгості» реалізації процесів життєвого циклу.

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

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

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

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

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

0 коментарів

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