Функціональна безпека, частина 4 з 4. Процеси управління та оцінювання



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

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

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

У цій статті досить абстрактні вимоги до управління функціональної безпекою інтерпретовані для впровадження в робочі процеси. Ця інформація перевірена і відшліфована на практиці декількох проектів по сертифікації.
Процесна інженерія – нудно це чи ні? Саме процеси дозволяють масштабувати IT-бізнес. Мені особисто доводилося спостерігати, як впровадження процесів в розробку призводило до серйозного професійного зростання, як виконавців, так і всієї компанії. І навпаки, «затики» і так звана «недоцільність» впровадження добре структурованих процесів свідчили про незрілість і інших серйозних проблем.
Отже…

попередній статті була розглянута структура вимог щодо функціональної безпеки (див. малюнок 1). Зараз ми зупинимося на двох аспектах: управління функціональної безпекою (Functional Safety Management) й оцінювання функціональної безпеки (Functional Safety Assessment).



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

План управління функціональної безпекою (Functional Safety Management Plan)

Процеси управління функціональної безпекою багато в чому співзвучні з процесами Project Management (PM) і Capability Maturity Model Integration (CMMI).

Розглянемо, яким чином може бути організовано управління функціональної безпекою (Functional Safety Management), щоб відповідати вимогам МЕК 61508 та інших пов'язаних стандартів (IEC 61511, IEC 62061, ISO 26262, EN 50129, IEC 62304, etc.).

Такі вимоги містяться у розділі 6, який входить в МЕК 61508-1,2,3. Основний обсяг вимог представлений в МЕК 61508-1; в МЕК 61508-2 є лише посилання на частину 1, МЕК 61508-3 міститься доповнення в частині управління конфігурацією програмного забезпечення.

Тепер спробуємо розібратися в цих вимогах і діях, необхідних, щоб цим вимогам відповідати. На практиці найкраще для цього розробити спеціальний документ – «План управління функціональної безпекою» (Functional Safety Management Plan, FSMP). Такий план буде включати в себе кілька напрямків:
— управління персоналом (Human Resource Management);
— управління конфігурацією (Configuration Management);
— вибір і оцінювання інструментальних засобів розробки (Tools Selection and Evaluation);
— верифікація та валідація (Verification and Validation);
— управління документацією (Documentation Management);
— оцінювання функціональної безпеки (Functional Safety Assessment).

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

Крім того, FSMP повинен містити наступні розділи (вони достатньо прості, або входять за рамки даної публікації і будуть розглянуті в запланованої публікації за описом життєвого циклу):
— політика і стратегія проекту (Project Policy and Strategy) – це досить декларативне опис того, як і навіщо будуть досягатися цілі проекту; власне кажучи, можна в цій частині резюмувати основні положення FSMP;
— управління постачальниками (Suppliers Management) включає взаємодію з постачальниками продукції і послуг, що впливають на забезпечення функціональної безпеки; це вимога прийшло з системи менеджменту якості (ISO 9001); в термінах Project Management аналогом є управління закупівлями; МЕК 61508 вимагає, щоб у постачальників діяла система менеджменту якості; якщо у постачальників є сертифікат ІСО 9001, то проблем не виникає (і навпаки);
— інформаційна безпека (Security); МЕК 61508 лише побіжно говорить про це важливе властивість, що, звичайно, не означає, що цьому аспекту не приділяється увага; ці властивості описані в інших стандартах, та сертифікація за їх вимоги являє собою окремий процес; що стосується розглянутої тут процесної складової, то вона, принаймні, не суперечить вимогам до системи менеджменту інформаційної безпеки (наприклад, сертифицируемой згідно ISO 27000);
— життєвий цикл функціональної безпеки (Functional Safety Life Cycle) повинен бути поетапно описано в FSMP; ми розглянемо цю складову в окремій публікації, так само, як і примикає до неї процес трасування вимог (Requirement Tracing).

Таким чином, розглянута структура FSMP представлена нижче у вигляді Mind Maps.



Малюнок 2. Структура Плану управління функціональної безпекою (Functional Safety Management Plan, FSMP)

Як вже було сказано, багато положень в управлінні функціональної безпекою перетинаються або ж безпосередньо запозичені з управління проектами. Крім того, застосування управління проектами рекомендується МЕК 61508, як один з методів захисту від систематичних відмов. Тому, такі інструменти, як: статут проекту, план проекту на основі WBS, Action and Bug Trackers і т. п. гаряче вітаються і рекомендуються до використання. Я ж зупинюся на тому, що повинно бути виконано відповідно до вимог стандарту.

Управління персоналом (Human Resource Management)

В принципі, якщо у компанії вже застосовується методологія Project Management (PMBOOK) або щось схоже (наприклад, CMMI), то, як правило, нічого особливого в цьому напрямі робити не доведеться. IEC 61508 вимагає виконати прагматичні дії:
— призначити відповідальних осіб для виконання всіх необхідних дій; оскільки тут же йдеться про необхідність координації дій, пов'язаних із забезпеченням та оцінюванням функціональної безпеки, то доцільно призначити так званого Functional Safety Coordinator (або можна також покласти такі функції менеджера проекту);
— визначити процедури комунікації між посадовими особами проекту, включаючи сторонніх учасників;
— розробити всі необхідні процедури, які перекривали б всі напрямки, перераховані в FSMP;
— організувати необхідне навчання персоналу, що гарантує підтримку компетенцій на необхідному рівні.

Виходячи з вищесказаного (а також, з особистого досвіду), основними інструментами управління персоналом в подібних проектах є оргдіаграмма (Organizational Chart) і матриця компетенцій (Competency Matrix).
Для детального планування управління персоналом розробляємо відповідний план (Human Resource Management Plan). Зазначимо, що цей план належить не до організації в цілому, а лише до учасників сертифікованого проекту по розробці продукту (або система), важливого для безпеки. В ньому повинні міститись (див. малюнок 3):
— організаційна діаграма проекту з описом проектних ролей;
— список учасників проекту з зазначенням проектних ролей і відповідальності за планування і виконання робіт на тих чи інших етапах життєвого циклу;
— матриця компетенцій і висновки про достатність або нестачу компетенцій призначаються виконавців (тобто які знання і вміння потрібні для конкретної проектної ролі і наскільки їм відповідає конкретний співробітник); тут може виникнути питання: «а як же можуть бути призначені люди з недостатніми компетенціями?»; у реальному світі, однак, дефіцит ресурсів, в першу чергу, людських спостерігається завжди; позитивна новина при цьому полягає в тому, що в разі некритичного нестачі компетенцій багатьох виконавців можна навчити відсутньою навичкам і знанням;
— заходи з навчання персоналу, спрямовані на досягнення і підтримання зазначених вище компетенцій, критичних для виконання проекту; плани та звіти по тренінгам повинні документуватися;
— план комунікацій учасників проекту;
— лист з підписами персоналу, що свідчать про ознайомлення з даними планом.



Малюнок 3. Структура Плану управління людськими ресурсами (Human Resource Management Plan)

Управління конфігурацією (Configuration Management)

Даний напрямок також досить відоме і методично відпрацьований, оскільки перегукується з PMBOOK і CMMI. У термінах функціональної безпеки в управління конфігурацією також включено управління змінами (Change Control) і реалізація модифікацій програмного забезпечення і устаткування, включаючи зняття з експлуатації. В цю ж область потрапляє і аналіз небезпечних подій, оскільки різні події є входом для внесення змін. Також багато корисні положення можна почерпнути з стандарту IEEE 828 Standard for Software Configuration Management Plan і, зрозуміло, з блогів авторів хабра, наприклад, «Записки відставного сиэмщика» @Aguary.

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



Малюнок 4. Типові елементи конфігурації (Configuration Items)

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

Управління конфігурацією безпосередньо залежить від застосовуваних інструментів, проте можна виділити деякі загальні моменти, які необхідно включати в План управління конфігурацією» (Configuration Management), такі як (див. малюнок 5):
— ролі та відповідальність учасників проекту в процесі управління конфігурацією; з ключових учасників проекту слід організувати групу з управління конфігурацією і змінами з залученням всіх тих осіб, думка яких важливо враховувати при внесенні змін;
— підхід до планування і супроводу процесу управління конфігурацією;
— ресурси процесу управління конфігурацією, в першу чергу, застосовуваний інструментарій (SVN, Git, etc.);
— процедура ідентифікації всіх компонентів конфігурації (Configuration Items) і формування базових версій (baselines);
— процедура застосування інструментарію для контролю версій програмних і апаратних компонентів продукту та для врахування їх статусу;
— процедура доступу до компонентів конфігурації і резервного зберігання;
— процедура і періодичність проведення аудитів конфігурації;
— процедура аналізу і усунення виявлених дефектів, в тому числі, виявлених у процесі експлуатації (це один з можливих входів для наступного пункту – Change Control);
— процедура контролю внесення змін (Change Control), включаючи аналіз впливу змін (Impact Analysis) і перевірку коректності внесення змін.



Малюнок 5. Структура Плану управління конфігурацією (Configuration Management Plan)

Процедура контролю внесення змін критично важлива при впровадженні та сертифікації процесів. Для формалізації зазвичай застосовується поетапна обробка запитів на внесення змін (Change Request). Етапи внесення змін представлені нижче на діаграмі (див. малюнок 6) та включають в себе:
Submit – надходження запиту на внесення змін, причиною може бути будь-яка корекція або доопрацювання;
Approve – розгляд і формальне затвердження запиту; зрозуміло, запит може бути відхилений, тоді наступні етапи не виконуються;
Impact Analysis – аналіз вплив запиту на функціонал, безпека, обсяг і вартість робіт і т. д.; тут же визначається не тільки обсяг розробки, але зміни документації, тестування та інших перевірок, пов'язаних з верифікацією та валідацією;
Implement – безпосередня реалізація змін;
Verify – виконання (можливо, поетапне) різного роду верифікаційних перевірок в частині внесених змін;
Close – формальне закриття запиту на внесення змін.



Малюнок 6. Процес управління маєтками (Change Control), заснований на обробці запитів на внесення змін (Change Request)

Вибір і оцінювання інструментальних засобів розробки (Tools Selection and Evaluation)

Дії по вибору та оцінювання інструментальних засобів (ІВ) тісно примикають до управління функціональної безпеки, хоча вимоги викладені в МЕК 61508-3 (7.4.4 Requirements for Support Tools, including Programming Languages).

Залежно від ступеня впливу на кінцевий продукт (систему та програмне забезпечення), інструментальні засоби класифікуються наступним чином:
— інструментальні засоби класу T1 не генерують виходи, які безпосередньо впливають на виконавчий код; сюди можна віднести тестові та графічні редактори, засоби управління конфігурацією (ті, які безпосередньо не генерують код), Action & Bug Tracker;
— інструментальні засоби класу T2 підтримують тестування та інші види верифікації (наприклад, статичний аналіз коду або аналіз повноти тестового покриття); при цьому безпосередній вплив на виконуваний код не виявляється, однак, проблема в засобах тестування може призвести до того, що помилки у програмному забезпеченні, можливо, не будуть виявлені; до даного класу повинні бути віднесені не тільки програмні засоби, але і програмно-апаратні симулятори вхідних/вихідних сигналів; слід зазначити, що до класу T2 також можуть бути віднесені засоби проектування механічних, електричних і електронних компонентів (наприклад, друкованих плат);
— інструментальні засоби класу T3 генерують виходи, які безпосередньо впливають на виконавчий код, до них відносяться транслятори і компілятори, скрипти для підтримки збірок і SCADA у частині конфігурації контролерів.



Малюнок 7. Класифікація типових інструментальні коштів для проектів, пов'язаних з функціональної безпекою

Обґрунтування можливості застосування компіляторів для цілей функціональної безпеки являє собою найбільшу проблему, оскільки вимоги до них такі, що повинно бути проведено повне тестування всіх функцій, що впливають на генерацію виконуваної коду. Від розробника отримати таку інформацію в приватному порядку навряд чи вдасться, а самостійно проводити 100% тестування чужого компілятор – це теж мало підйомне завдання. На щастя, в останні 5 років багато провідні виробники програмованих чіпів (CPU, FPGA/CPLD) вийшли на ринок з вже сертифікованими по вимогам МЕК 61508 версіями компіляторів. Такий інструментарій може бути використаний для розробки продуктів, що відповідають вимогам МЕК 61508. Проблеми тут дві: висока вартість багатьох таких інструментів (як правило, тисячі доларів) і те, що вони сумісні далеко не з усіма мікросхемами, підтримуваними типовими версіями компіляторів.

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

На що слід звернути увагу при використанні інструментальних засобів? Є кілька положень, заданих у вимогах МЕК 61508:
— для інструментальних засобів класів T2 і T3 повинні бути доступні специфікації вимог або користувацька документація, які однозначно описують те, як відбувається функціонування;
— для інструментальних засобів класів T2 і T3 повинно бути документально підтверджено їх відповідність специфікації вимог або користувальницької документації, наприклад, у вигляді сертифіката;
— повинні контролюватися версії використовуваних інструментальних засобів, оскільки не для всіх версій можуть виконуватися зазначені умови; усі учасники проекту повинні використовувати одну і ту ж версію; для переходів між версіями повинна застосовуватися відповідна процедура;
— якщо інструментальні засоби використовуються як єдиний технологічний комплекс (наприклад, на підставі специфікації генеруються код і тести), то повинна бути протестована їх сумісність між собою.

Для забезпечення відповідності зазначеним вимогам доцільно розробити спеціальний Звіт щодо вибору та оцінювання інструментальних засобів (Tools Selection and Evaluation Report, TSER). У нього слід включати:
— опис використовуваного стека інструментальних засобів (як програмних, так і апаратних, як комерційно доступних, так і власної розробки) використовуються для розробки продукту, його випробувань, а також підтримуючих процесів (управління конфігурацією, набір текстових документів, управління проектом і т. д.); для кожного з інструментів слід вказати: тип (для підтримки якого процесу використовується), найменування, номер версії, назва постачальника, клас (T1, T2 або T3), що генеруються виходи в термінах компонентів конфігурації (Configuration Items);
— результати оцінювання (аналізу) інструментальних засобів згідно з набору заданих критеріїв, таких як, наприклад: виконувані функції та їх застосування в даному проекті, досвід використання, доступна документація, інформація про постачальника (репутація на ринку, система менеджменту якості, підхід до управління конфігурацією тощо), вплив на безпеку продукту, виявлені і усунені помилки, можливі ризики використання з точки зору прояву відмов і стратегія управління даними ризиками.

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

Верифікація і валідація (Verification and Validation)

Реалізація даного процесу залежить від структури обраного життєвого циклу, тому деталі є сенс розглянути в запланованої публікації на тему життєвого циклу функціональної безпеки (Functional Safety Life Cycle).

Слід зазначити, що верифікація і валідація включають в себе не тільки тестування, але і огляди проектних документів, аналіз видів і наслідків відмов (Failure Mode and Effect Analysis), статичний аналіз коду і т. п.

В цілях управління функціональної безпекою є сенс розробити верхнеуровневый план верифікації та валідації (Verification and Validation (V&V) Plan), що включає наступні положення (див. малюнок 8):
— опис організації процесу V&V і розподіл ресурсів на виконання;
— етапи V&V у зв'язку з етапами розробки;
— методи та інструментарій для виконання V&V;
— вимоги до документування результатів V&V;
— вимоги до обробки виявлених аномалій.



Малюнок 8. Структура Плану верифікація та валідації управління конфігурацією (Verification and Validation Plan)

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

Керування документацією (Documentation Management)

Вимоги до документації наведено в розділі 5 МЕК 61508-1. Основні вимоги наступні:
— документи повинні містити достатню інформацію для наступних стадій розробки, так і для верифікації результатів поточної стадії;
— документи повинні містити достатню інформацію, як для забезпечення, так і для оцінювання функціональної безпеки;
— документи повинні бути доступні для посадових осіб проекту з розробки та сертифікації продуктів (та систем), пов'язаних із забезпеченням безпеки;
— документи повинні мати номер версії і дату останньої зміни; зміни в документи повинні вноситися відповідно до згаданої вище процедури управління змінами (Change Control).

Для детального планування управління документацією розробляємо відповідний план (Documentation Plan). Зазначимо, що цей план належить не до організації в цілому, а лише до учасників сертифікованого проекту по розробці продукту, важливого для безпеки (або системи). В ньому повинні міститись (див. малюнок 9):
— вимоги до ідентифікації, розробки, оформлення, узгодження і затвердження документів;
— процедура огляду та критерії оцінювання документів (наприклад, у вигляді чек-листів); зокрема, критеріями оцінювання документів згідно МЕК 61508 є: точність, стислість, зрозумілість, придатність та відповідність призначенню, доступність для використання і сопровождаемость;
— перелік документів за проектом та розподіл відповідальності за розробку;
— процедура організації доступу і права доступу учасників проекту до документів;
— процедура внесення змін в документи, політика обліку і зміни версій;
— вимоги до застосування електронної системи документообігу (EDCS – Electronic Document Control System) і структура проектного репозиторію.



Малюнок 9. Структура Плану документування (Documentation Plan)

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

Документи, що розробляються в проекті, пов'язаному із забезпеченням функціональної безпеки. включають наступні типи (див. малюнок 10):
— документи по плануванню функціональної безпеки, розглянуті в цій статті;
— специфікація вимог (Safety Requirements Specification, SRS) і системна архітектура (System Architecture Design, SAD);
— проект апаратних засобів, званий також конструкторською документацією (Hardware Design);
— проект програмного забезпечення (Software Design);
— документи з верифікації та валідації;
— документи, що відносяться до так званого кваліфікаційного тестування обладнання (Equipment Qualification Testing) на стійкість до екстремальних впливів; зазвичай задаються рівні таких впливів, як кліматичні (температурно-вологісні), механічні (удари, пошук резонансу, транспортна тряска, сейсміка), електро-магнітні;
— розглянуті вище документи, що відносяться до інструментальним засобам (керівництва користувача, специфікації вимог, сертифікати, що підтверджують відповідність вимогам, інформація про постачальників);
— розглянуті вище документи з управління змінами (Change Control);
— користувацька документація на поставлений продукт, у тому числі керівництво користувача безпеки (Product Safety Manual);
— керівництва, процедури та інструкції, що використовуються в проекті для організації роботи; такі документи можуть бути використовувати прийняті в компанії практики або можуть бути розроблені спеціально для проекту, пов'язаного з функціональної безпекою.



Малюнок 10. Класифікація документації для проектів, пов'язаних з функціональної безпекою

Оцінювання функціональної безпеки (Functional Safety Assessment)

Тепер подивимося, як оцінюється функціональна безпека.
Для цього в ході операційної діяльності проводяться періодичні аудити функціональної безпеки (Functional Safety Audit).
Крім того, при проведенні сертифікації виконується оцінювання процесів і продукту сертифікує організацією, за підсумками якого видається сертифікат відповідності. Найбільш відомими сертификаторами функціональної безпеки є група компаній TÜV.
Аудити повинні проводитися згідно з заздалегідь розробленим планом (Functional Safety Audit Plan). У планах повинні бути визначені:
— періодичність проведення аудитів (наприклад, по завершенню кожного з етапів розробки);
область оцінювання з точки зору продуктів і процесів;
— залучені організації та інші необхідні ресурси;
— рівень незалежності адиторов; аудити можуть бути внутрішніми, тоді аудиторами є учасники проекту, незадіяних у процесах, які піддаються аудиту; крім того, сертифицирующая організація також може брати участь у періодичних аудитах; взагалі, питання незалежності при оцінюванні безпеки має свої традиції в різних галузях промисловості;
— компетентність осіб, що виконують аудит;
— очікувані результати;
— організація дій по усуненню недоліків.
Вихідними даними для складання чек-листа аудиту є вимоги FSMP та інших підпорядкованих планів, розглянутих в даній статті.
За результатами проведення аудитів повинні бути випущені відповідні Звіти про аудити функціональної безпеки (Functional Safety Audit Reports).

Висновки

У статті проаналізовано положення МЕК 61508, що відносяться до управління функціональної безпекою (Functional Safety Management) й оцінювання функціональної безпеки (Functional Safety Assessment).
Реалізуються процеси відповідають основним положенням управління проектами, а також програмної і системної інженерії.
Інтерпретація вимог може дещо відрізнятися для різних галузей індустрії, оскільки для них розроблені власні стандарти, які, тим не менш, багато в чому гармонізовано з МЕК 61508.
Пропонований читачеві матеріал підтверджений досвідом (6 років в успішних проектах з сертифікації) при роботі з сертифицирующими компаніями exida і TÜV.
Джерело: Хабрахабр

0 коментарів

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