Англійська мова для критичних систем безпеки: ISO 26262, FMEA, і випадки безпеки

Критичні системи безпеки — в автомобільній, аерокосмічній, медичних пристроях, залізниці і промисловому контролі — вимагають специфічного словника, заснованого на міжнародних стандартах, таких як ISO 26262, IEC 61508 і DO-178C. Інженери, що працюють в цих областях, повинні писати і читати точні технічні документи, документи з безпеки та нормативні документи. Цей посібник містить основні слова англійської мови.

Основний словник безпеки

Term	Definition
ASIL	Automotive Safety Integrity Level — a risk classification from ASIL A (lowest) to ASIL D (highest) in ISO 26262
SIL	Safety Integrity Level — the equivalent classification in IEC 61508 (SIL 1 to SIL 4)
FMEA	Failure Mode and Effects Analysis — a systematic method for identifying potential failures and their consequences
Fault tree analysis (FTA)	A top-down method for analysing the causes of an undesirable event
Safety case	A structured argument with evidence that a system is safe for a specific use in a specific environment
Fail-safe	A design principle where a failure results in the safest possible state
Fail-operational	A design principle where a system continues to function despite a failure
Hazard	A potential source of harm
Risk	The combination of the probability of harm and the severity of that harm
Mitigation	A measure that reduces the probability or severity of a hazard

Філософія і структура

Аналіз режиму та ефектів невдачі є систематичним методом, заснованим на таблицях. Знання словника дозволяє вам читати і писати документи FMEA.

FMEA Column	Definition
Failure mode	The way in which a component or function could fail
Effect	The consequence of the failure mode at the system level
Cause	The mechanism that leads to the failure mode
Severity (S)	A rating (typically 1–10) of how serious the effect is
Occurrence (O)	A rating of how likely the failure mode is to occur
Detection (D)	A rating of how easily the failure can be detected before it causes harm
RPN	Risk Priority Number — S × O × D; used to prioritise corrective actions
Corrective action	A design or process change that addresses the failure mode

** Приклад рядка FMEA (опис простою англійською): **

• “Датчик положення дроссельної заслінки може показувати помилкові показники (режим відмови). Це може призвести до непередбаченого прискорення (ефект). Причиною є дрейф датчика через температурні цикли. Серйозність: 9. Випадок 3. Визначення: 4. Площа 108 га. Виправлення: додайте надлишковий датчик з логікою перевірки».*

Використовує деревний лексикон

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

Term	Meaning
Top event	The undesirable event being analysed
Basic event	A root-level failure that cannot be decomposed further
Intermediate event	A fault that results from a combination of lower-level events
AND gate	All inputs must occur for the output to occur
OR gate	Any input is sufficient to cause the output
Cut set	A combination of basic events whose simultaneous occurrence leads to the top event
Minimal cut set	The smallest set of basic events sufficient to cause the top event

Мова справедливості

Причина безпеки є структурованим аргументом. Мова є формальною, точною і доказовою.

** Структура аргументів випадків безпеки (структурна нотація мети): **

• Ціль: “Гальмівна система безпечна для використання на дорожніх транспортних засобах, що рухаються зі швидкістю до 200 км/год у звичайних і неблагоприятних погодних умовах.”
• ** Стратегія: ** *“Аргументація щодо фаз життєвого циклу: вимоги, проектування, реалізація і перевірка.” *
• ** Під- мета: ** “Вимоги до гальмівної системи повні і коректні.”
• ** Доказ: ** *“Вимоги були переглянуті незалежним оцінювачем безпеки і виявлені відповідними ISO 26262 Частина 8.” *

** Формальні мовні шаблони в документах безпеки:**

• “Буде показано, что…”
• “Система повинна…”
• “Доказів відповідності надано в…”
• “Це твердження підтверджується…”
• “Наступні залишкові ризики були визначені і прийняті…”

Регулятивна мова документів

Стандарти безпеки використовують модальні дієслова з певними значеннями:

Modal	Standard meaning
shall	Mandatory requirement
should	Recommended but not mandatory
may	Permitted but not required
can	Describes a capability, not a requirement

Це відрізняється від повсякденної англійської. У документах з безпеки «shall» завжди є жорсткою вимогою — невідповідність повинна бути виправдана.

Приклади висловлювань

1. «Привод стояночного гальма отримав оцінку ASIL B на основі HARA, з урахуванням помірної ймовірності виникнення та критичної тяжкості на швидкостях транспортних засобів нижче 10 км/год»
2. «FMEA визначив режим високої RPN-несправності на модулі живлення; коригувальна дія полягає в додаванні надлишкових рейок живлення з незалежним моніторингом»
3. «Случай безпеки для автономної функції аварійного гальмування охоплює дванадцять рівнів надійності і підтримується даними моделювання, результатами тестування апаратного забезпечення і незалежним оцінюванням.»
4. «Була розроблена безпечна відповідь: якщо зв’язок між первинним і вторинним блоками управління буде втрачено, система за замовчуванням буде максимальною підтримкою гальмування»
5. «Аналіз дерева порушень визначив три мінімальних набори відрізків для верхньої події «незапланований боковий рух»; всі три були розглянуті в переглянутій архітектурі»

На практиці: Навігація комунікації в перегляді безпеки

Будьмо чесними – переклад складних інженерних концепцій з вашої рідної мови на точну англійську може бути схожим на навігацію в густому лісі. Це не просто про те, щоб знати * визначення * таких термінів, як “ASIL” або “FMEA”; це про послідовне використання їх правильно в конкретному контексті розробки безпечних критичних систем. Зазвичай, причиною для невдоволення людей, для яких мова не є рідною, є незначні відмінності у фразуваннях, які можуть значно вплинути на ясність і, що найважливіше, продемонструвати досконале розуміння ваших колег.

Під час нещодавнього перегляду коду нового модуля інтеграції датчиків для автомобільного застосування (націленого на ISO 26262), я помітив особливо цікавий обмін. Розробник, назовемо його Цзян, реалізував резервну систему, де первинні показання датчика постійно порівнювалися з резервними показаннями, отриманими з абсолютно незалежного джерела. Його PR-опис просто стверджував: “Збільшений моніторинг датчиків”. Хоча технічно точний, йому бракувало необхідних деталей для критичного середовища безпеки. Мій коментар, який намагався бути конструктивним і ясним, зосередився на причинах, що стоять за надлишковістю. Я запропонував: “Цзян, ми можемо розглянути обґрунтування цього зайвого моніторингу? Зокрема, які режими несправностей ми зменшуємо за допомогою цього підходу, і як це збігається з нашим аналізом FMEA? Додання речення, що описує рівень ASIL, пов’язаний з вимогами безпеки цього модуля, також зміцнить документацію. “Це змінило розмову від простого спостереження до глибшого обговорення про зменшення ризику і прослуховування - елементи, що є життєво важливими для надійного випадку безпеки.

Інша ситуація виникла під час обговорення Slack щодо запропонованої зміни до механізмів безпеки системи. Початкова пропозиція, складена членом команди, чия перша мова була іспанською, використовувала такі фрази, як «система автоматично зупиниться» без вказівки * як * це зупинення відбулося або які діагностичні перевірки були введені. Ця відсутність деталей викликала негайні занепокоєння. Пізніше пояснення, викликане моїм вказівкою на необхідність кількісних критеріїв — «Чи можемо ми визначити умови, що викликають автоматичне зупинення? Які вимірювані параметри ми моніторимо, щоб забезпечити безпечне вимкнення?» — допомогло вдосконалити дизайн і врешті-решт збудувати впевненість у його наслідках для безпеки.

Поняття цього нюансового спілкування є ключовим. Не достатньо просто знати * що * ви говорите; мова йде про передачі * чому * ви це говорите, завжди посилаючись на встановлений аналіз, як FMEA і забезпечення відстежуваності через вашу документацію. Цей рівень точності створює довіру і демонструє прихильність до суворих вимог ISO 26262.

Ось приклад, який показує, як можна скористатися grep для пошуку певних ключових слів у файлах журналів, пов’ язаних з моніторингом безпеки, що є звичайним завданням під час розслідування інциденту:

grep -i "sensor_failure" /var/log/system_monitoring.log | sort | uniq -c

За допомогою цієї команди можна шукати у файлі /var/log/system_monitoring.log випадки « sensor_ failure » (не враховуючи регістру), впорядковувати результати за частотою, а потім показувати кількість кожного випадка. Цей вивід може бути безцінним при перегляді журналів після аномалії або потенційної проблеми безпеки - чітко демонструючи здатність видобувати критичні дані зі складних систем.