Результати HARA-аналізу мають вирішальне значення для оцінки того, чи може продукт розроблятися в режимі «звичайного» контролю якості (QM-рівень), або розробка має відбуватися за одним з рівнів ASIL A – D або SIL (за типом стандарту; далі за простотою (A)SIL).

HARA або FMEA?

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

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

В рамках HARA-аналізу ключовим питанням є: до яких загроз може призвести вплив оцінюваної деталі?

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

Ключовим питанням аналізу FMEA є: Що може вийти з ладу і до чого це може призвести?

Для FMEA та HARA загальним для аналізу є те, що оцінка відбувається в контексті.

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

Як зробити HARA аналіз

Тут ми описуємо аналіз HARA на основі ISO 26262-3. Однак ця процедура відповідає і іншим стандартам, наприклад, Mil Std 882D.

Основними кроками аналізу HARA є:

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

Результатами аналізу є

Проекти заходів, що зменшують загрози
Включення в клас безпеки ASIL / SIL (За типом використовуваного стандарту)

Запобіжні заходи повинні мати практичні виходи

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

Редунданс

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

Режим безпеки (Safety mode)

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

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

Збільшення надійності

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

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

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

Чому системна підтримка корисна для HARA

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

Документація HARA

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

Вічна зв'язність

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

Завдяки системній та процесовій підтримці HARA в AyMINE ви матимете не лише якісну документацію, але й зв’язок із документацією про продукт та проектом. А також процесуальна підтримка.

Вас може зацікавити

Потрібен стандарт ISO 26262 для нового продукту? Розглянемо наші стандарти навчання.