HARA продукту

Hazard & Risk Analysis - це початковий етап прийняття рішення про віднесення продукту до класу безпеки. Системна підтримка допоможе вам зробити та документувати як аналіз, так і його перебіг.

[placeContent]

Результати 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 є:

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

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

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

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

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

Редунданс

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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