Функціональна безпека електросамоката: безпекова цілісність як шоста cross-cutting infrastructure axis — IEC 61508:2010 (E/E/PE безпеково-пов'язані системи, SIL 1-4) + ISO 26262:2018 (автомобільна FuSa, ASIL A-D) + ISO 13849-1:2023 (безпекові частини машин, PLr a-e, категорії B/1/2/3/4) + IEC 62061:2021 (SIL CL для машинних E/E/PES) + EN 17128:2020 Annex G (PLEV functional safety requirements) + IEC 60812:2018 FMEA + IEC 61025:2006 FTA + IEC 61709:2017 reliability data + MISRA C:2023 software safety subset + ISO/PAS 21448:2022 SOTIF + IEC 61511 process industry + IEC 60730-1:2024 controls + UL 991 + UL 1998 + DO-178C analogy

У серії інженерного гайду ми описали акумуляторну батарею з BMS і thermal runaway intro, гальмівну систему, мотор і контролер, підвіску, шини, світло і видимість, раму й вилку, display + HMI, зарядний пристрій SMPS CC/CV, connector + wiring harness, IP-захист, bearingи з ISO 281 L10, стеблину і механізм складання, деку, handgrip + lever + throttle, колесо як assembly, інженерію різьбових з’єднань як joining-axis, термоменеджмент як heat-dissipation cross-cutting axis, EMC/EMI як interference-mitigation cross-cutting axis, кібербезпеку як interconnect-trust cross-cutting axis та NVH як acoustic-vibration-emission cross-cutting axis. Ці 22 engineering-axis описали окремі підсистеми, способи з’єднання, розсіювання тепла, співіснування електромагнітних полів, встановлення довіри та акустично-вібраційне випромінювання — але жодна з них не описала, наскільки кожна підсистема має право відмовляти: яка ймовірність небезпечної відмови є припустимою, як її квантифікувати, як її знижувати, і як довести, що залишковий ризик нижчий за регуляторний поріг.

Сучасний електросамокат — це сукупність 5+ safety-critical підсистем: (a) motor controller, чия “stuck-open” відмова MOSFET’а спричиняє unintended acceleration; (b) brake actuator (mechanical lever + hydraulic line / disc + electronic regen), чия “loss-of-stopping-power” відмова веде до неможливості зупинити рух; (c) throttle position sensor (Hall ефект / потенціометр), чий drift спричиняє самовільне набирання швидкості; (d) BMS (Battery Management System), чия “fail-overcurrent” або “fail-overtemperature” відмова веде до thermal runaway і пожежі; (e) display HMI, чий “frozen screen” або “wrong-info” режим приховує critical info від водія. Кожна з цих відмов може спричинити серйозну травму або fatality, тож функціональна безпека як інженерна дисципліна квантифікує, наскільки часто ці відмови можуть статися і як спроєктувати систему, щоб ймовірність небезпечної відмови була нижча за allocated target (наприклад, < 10⁻⁶ небезпечних відмов за годину для SIL 2 high-demand mode per IEC 61508-1 § 7.6.2.9 Table 3).

Це двадцять третя engineering-axis deep-dive у серії гайду — і шоста cross-cutting infrastructure axis (паралельна до fastener як joining, thermal management як heat-dissipation, EMC/EMI як interference-mitigation, cybersecurity як interconnect-trust і NVH як acoustic-vibration-emission). Функціональна безпека описує спосіб встановлення припустимого рівня небезпечних відмов, який присутній у кожній попередній axis: BMS з ASIL-rated firmware, brake actuator з PLr-d redundancy, motor controller з safety MCU lockstep CPU, throttle з 2oo2 voting на dual Hall sensors, display з ISO 26262-compliant graphics stack. Завдання FuSa-інженерії — квантифікувати hazard rate (HARA), алокувати target SIL/ASIL/PL до кожної функції, спроєктувати hardware architecture з потрібним HFT та SFF, верифікувати software за MISRA C:2023 та structural coverage, підтвердити через FMEA + FTA + FMEDA, що PFD або PFH вкладається у allocated budget, і довести compliance через safety case (GSN-нотація).

Особливість контексту PLEV (Personal Light Electric Vehicle): e-scooter не входить у scope ISO 26262 (passenger cars і light trucks ≤3,5 t per § 1 “Scope” 2018 edition), не входить у scope IEC 61511 (process industry safety instrumented systems), частково покривається IEC 62061 (machinery), формально покривається EN 17128:2020 Annex G (PLEV functional safety requirements, але якісно, без quantitative SIL/PL targets), і за аналогією використовує IEC 61508 (foundational E/E/PE safety standard для будь-якого електронного/програмованого захисту). Тож industry-baseline тут — це voluntary compliance з ASIL B/B+ для motor controller (за аналогією до ISO 26262-compliant ECU постачальників типу Bosch, Continental, Nidec), ISO 13849-1 PLr d для brake-by-wire і throttle-by-wire (за аналогією до machinery safety), і EN 17128:2020 Annex G як обов’язковий floor для CE-marking на ринку ЄС.

1. Чому функціональна безпека — окрема cross-cutting axis

Функціональна безпека — це не просто “не зламається”. Це система, у якій кожен елемент має квантифіковану ймовірність небезпечної відмови:

Елемент FuSa-системи	Що описує	Governing standard
Hazard analysis and risk assessment (HARA)	Перелік можливих небезпек з оцінкою severity (S0-S3) × exposure (E0-E4) × controllability (C0-C3) → ASIL A/B/C/D або QM	ISO 26262-3:2018 § 6 “Hazard analysis and risk assessment”, ISO 12100:2010 machinery risk
Safety integrity level allocation	Цільовий рівень безпеки для функції — SIL 1/2/3/4 (IEC 61508), ASIL A/B/C/D (ISO 26262), PLr a/b/c/d/e (ISO 13849-1), SIL CL 1/2/3 (IEC 62061)	IEC 61508-1:2010 § 7.4-7.6, ISO 26262-3:2018 § 7, ISO 13849-1:2023 § 4.3, IEC 62061:2021 § 5
Hardware safety architecture	Конфігурація 1oo1 / 1oo2 / 2oo2 / 2oo3 + HFT (0/1/2) + SFF (<60% / 60-90% / 90-99% / ≥99%)	IEC 61508-2:2010 § 7.4.4 “Architectural constraints”, ISO 26262-5:2018 § 8 “Evaluation of hardware architectural metrics” (PMHF, SPFM, LFM)
Software safety lifecycle	V-model: REQ → design → implementation → unit test → integration test → system test → acceptance test; з MISRA C:2023 coding subset, MC/DC coverage для SIL 3+ / ASIL D	IEC 61508-3:2010, ISO 26262-6:2018, MISRA C:2023, DO-178C DAL A-E analogy
Failure rate quantification	λ (FIT — Failures In Time = відмов на 10⁹ годин), MTBF, PFD (low-demand) або PFHD (high-demand mode)	IEC 61709:2017 reference conditions, Siemens SN 29500-1, Telcordia SR-332 Issue 4, MIL-HDBK-217F Notice 2
Diagnostic coverage (DC)	Частка небезпечних відмов, які детектуються онлайн-діагностикою (BIST, watchdog, CRC, parity, ECC) — DC_low < 60%, DC_med 60-90%, DC_high 90-99%, DC_high+ ≥ 99%	IEC 61508-2:2010 § 7.4.4 Table 2, ISO 26262-5:2018 § 8.4.5
Safe failure fraction (SFF)	Частка безпечних відмов (S) + dangerous-detected (DD) у загальній кількості відмов — SFF = (λ_S + λ_DD) / λ_total	IEC 61508-4:2010 § 3.6.15, ISO 26262-5:2018 § 8.4.6
Hardware fault tolerance (HFT)	Кількість одночасних апаратних відмов, які система витримує без втрати безпекової функції	IEC 61508-2:2010 § 7.4.4 Table 3, ISO 26262-5:2018 § 8.4.7
Verification and validation	Static analysis (MISRA), dynamic analysis (coverage), formal methods (model checking), fault injection (HIL bench), accelerated life testing (HALT/HASS)	IEC 61508-3:2010 § 7.4-7.9, ISO 26262-6:2018 § 9-11, MIL-STD-810H Method 514.8
Safety case	Структурований аргумент (GSN — Goal Structuring Notation), що залишковий ризик ≤ припустимий per ALARP	UK MoD Defence Standard 00-56 Part 1, GSN Community Standard v3, ISO 26262-2:2018 § 6.4.5

Кожен з цих 10 елементів квантифікується: hazard rate з PHA, target SIL/ASIL/PL з risk graph, λ з IEC 61709, DC з diagnostic coverage analysis, SFF з architectural constraints, PFH_D з FMEDA. Якщо хоч один елемент не квантифіковано — система не може довести compliance, незалежно від суб’єктивної впевненості розробника. Це ключова відмінність FuSa від інженерії “best effort”: доказова дисципліна.

2. Risk reduction equation, ALARP, tolerable risk

Базове рівняння функціональної безпеки (IEC 61508-1 § 7.4.4):

$$R_\text{residual} = R_\text{unmitigated} \times \frac{1}{RRF}$$

де RRF (Risk Reduction Factor) — фактор зниження ризику завдяки безпековій функції. Для low-demand mode RRF = 1 / PFD_avg; для high-demand mode RRF = 1 / (PFH × T_mission). SIL 1 = RRF 10-100, SIL 2 = RRF 100-1 000, SIL 3 = RRF 1 000-10 000, SIL 4 = RRF 10 000-100 000 (IEC 61508-1 Table 3).

Tolerable risk — це прийнятна ймовірність небезпечної події на людину на рік. Industry benchmarks (HSE UK R2P2 2001, EN 50126-2 railway):

• Intolerable (verboten): > 10⁻³ fatalities/person/year — обов’язкове зниження
• ALARP zone: 10⁻³ … 10⁻⁶ — зниження “As Low As Reasonably Practicable”
• Broadly acceptable: < 10⁻⁶ — без подальших дій

ALARP-принцип (As Low As Reasonably Practicable, HSE UK 2001) вимагає зниження ризику до точки, де подальше зниження стає disproportionate до користі (cost-benefit analysis). Для e-scooter цей поріг визначається ринково: якщо кожне додаткове 10⁻⁷ зниження hazard rate коштує > $50 на сам апарат, виробник може аргументувати, що подальше зниження “не reasonably practicable”. HSE Q-CDF (Quantitative Cost-Disproportion Factor) типово 1-10 для індивідуальних ризиків.

GAMAB (Globalement Au Moins Aussi Bon, “globally at least as good”) і MEM (Minimum Endogenous Mortality, ~2 × 10⁻⁵/person/year) — альтернативні фреймворки з французької та німецької регуляторних шкіл, які встановлюють tolerable risk як не гірше, ніж існуючі еквівалентні системи (GAMAB) або нижче за природну минимальну смертність (MEM, EN 50126-2 Annex C).

3. SIL / ASIL / PLr / SIL CL cross-mapping

Чотири стандарти використовують різні шкали безпекової цілісності, але всі прив’язані до ймовірності небезпечної відмови за годину (PFH_D):

IEC 61508 SIL (high-demand)	ISO 26262 ASIL	ISO 13849-1 PLr	IEC 62061 SIL CL	PFHD (1/h)	RRF
—	QM (Quality Management)	a	—	10⁻⁵ … 10⁻⁴	10-100
SIL 1	ASIL A	b	SIL CL 1	10⁻⁶ … 10⁻⁵	100-1 000
SIL 2	ASIL B	c	SIL CL 2	10⁻⁷ … 10⁻⁶	1 000-10 000
SIL 3	ASIL C / D (для D без однієї відмови)	d	SIL CL 3	10⁻⁸ … 10⁻⁷	10 000-100 000
SIL 4	ASIL D (для extreme uncontrollable hazards)	e	— (≤ SIL CL 3)	10⁻⁹ … 10⁻⁸	100 000-1 000 000

Для e-scooter типові алокації (за аналогією до automotive supplier практики Bosch / Continental / Nidec 2022-2026):

• Motor controller throttle-stuck → unintended acceleration: ASIL B (S2 серйозна травма × E3 high exposure under throttle × C2 normally controllable by brake = ASIL B per ISO 26262-3 Table 4)
• Brake actuator loss of stopping power: ASIL D (S3 fatality × E3 high exposure × C3 difficult to control = ASIL D — найвищий рівень)
• Throttle position drift: ASIL B (S2 × E3 × C2 = B)
• BMS thermal runaway / overcurrent: ASIL C (S3 × E2 × C2 = C; ширші мітки спираються на UN R100, EN 50604-1)
• Display HMI critical info loss (speed, battery SoC, error indicator): ASIL A (S1 × E3 × C2 = A; інформативна, не actuation)
• Lighting headlight fail-dark при нічному ризику: ASIL B (S2 × E2 × C2 = B; відповідає брит. PAS 1881 категоризації)

Альтернативна формальна алокація через ISO 13849-1 risk graph (Annex A, fig. A.1): для brake-by-wire e-scooter — S2 (серйозна, реверсивна травма) × F2 (frequent exposure) × P2 (uncontrollable) → PLr d. Для throttle-by-wire — S1 × F2 × P2 → PLr c. Для motor controller short-stuck — S2 × F2 × P1 → PLr c.

4. Hazard identification: HARA + HAZID + HAZOP + STAMP

Першим кроком функціональної безпеки є виявлення усіх можливих hazardous events. Industry практикує 4 методології (інтегровані в ISO 26262-3 і IEC 61508-1):

Метод	Підхід	Краще для	Стандарт
PHA (Preliminary Hazard Analysis)	Brainstorm-сесія з check-list класів небезпек (механічна, електрична, теплова, хімічна, ергономічна) на ранній стадії concept design	Початкова concept phase	MIL-STD-882E:2012 § 4.4, AIChE PHA Best Practices
HAZID (Hazard Identification)	Структурований workshop з identification team (operator + designer + safety engineer + maintenance) і checklist специфічних до домену	Системний рівень, до архітектури	API RP 14J, DNV-OS-A101
HAZOP (Hazard and Operability)	Деталізація відхилень параметрів від project intent через guide-words (NO, MORE, LESS, AS WELL AS, REVERSE, OTHER) на кожному node системи	Деталізований design phase, process plants	IEC 61882:2016
STAMP / STPA (Systems-Theoretic Process Analysis)	Modern systems-theoretic метод (Leveson MIT 2012+), що моделює control loops і identifies UCAs (Unsafe Control Actions)	Складні adaptive системи з software-intensive control loops	Leveson “Engineering a Safer World” MIT Press 2012, STPA Handbook 2018

Для e-scooter STPA-приклад (Leveson STPA Handbook 2018 § 2.4):

• System control structure: Rider (human controller) → Throttle (input device) → Motor controller (computer controller) → Motor (controlled process) → Wheel (physical action) → Road (environment)
• Identified UCAs:
  • UCA-1: Motor controller activates motor when throttle is not pressed (unintended acceleration)
  • UCA-2: Motor controller does not deactivate motor when throttle is released (stuck throttle)
  • UCA-3: Motor controller deactivates motor when throttle is pressed (motor cut-out)
  • UCA-4: Motor controller activates motor for too long after brake is applied (regen-override)
• Causal scenarios для UCA-1: (a) BLE remote injection (covered у cybersecurity-engineering.md); (b) Hall sensor short to V_supply; (c) EMC pickup на ADC input (covered у emc-emi-engineering.md); (d) firmware race condition; (e) memory bit-flip через cosmic ray / alpha particle.

5. Hazard-by-subsystem matrix

Шість safety-critical підсистем e-scooter і їх типові hazardous events:

Підсистема	Hazardous event	S × E × C	ASIL	Mitigation (high-level)
Motor controller	Stuck MOSFET → unintended acceleration	S2 × E3 × C2	B	Dual-channel current sense, brake-priority override, watchdog firmware, contactor cut-off relay
Brake actuator (mechanical/hydraulic)	Hydraulic line burst / cable snap → loss of stopping	S3 × E3 × C3	D	Dual independent brakes (front + rear), redundant cable, hydraulic + mechanical parallel, brake light status indicator
Throttle position sensor	Hall sensor short-circuit / drift → input ramp from 0 to max	S2 × E3 × C2	B	2oo2 voting на dual Hall sensors з diverse manufacturing, plausibility check per ISO 26262-9 § 6.4.5
BMS (Battery Management System)	Overcurrent latch failure / thermal runaway	S3 × E2 × C2	C	Hardware overcurrent fuse + firmware OCP, NTC thermistor × N_cells, MOSFET cut-off, UL 2271 / UN 38.3 compliance
Display HMI	Frozen screen / wrong-info — водій не бачить critical state	S1 × E3 × C2	A	Watchdog refresh, dedicated error LED, audible buzzer fallback, redundant minimal LCD
Lighting (headlight + rear)	Fail-dark в нічних умовах	S2 × E2 × C2	B	Redundant LED arrays, hot-swap fallback, day-running light independent, ECE R148 / SAE J583 compliance

Шкала S × E × C per ISO 26262-3:2018 Tables 1-3:

• S (Severity): S0 нічого / S1 легкі та помірні травми / S2 серйозні та потенційно з ризиком життя травми (survival probable) / S3 ризик життя травми (survival uncertain) або fatality.
• E (Exposure): E0 неймовірно / E1 дуже мала (< 1% operating time) / E2 мала (1-10%) / E3 середня (10-50%) / E4 висока (> 50%).
• C (Controllability): C0 controllable in general / C1 simply controllable / C2 normally controllable (> 90% drivers) / C3 difficult to control or uncontrollable (< 90%).

6. FMEA worked example: BLE throttle injection

Failure Mode and Effects Analysis (IEC 60812:2018) — bottom-up метод, який для кожного компонента перелічує можливі режими відмов, наслідки, ймовірність (O), severity (S), detectability (D) і обчислює RPN = O × S × D.

Scenario: BLE-display надсилає throttle-injection команду до motor controller (CVE-class vulnerability documented у cybersecurity-engineering.md).

Component	Failure mode	Effect on system	S (1-10)	O (1-10)	D (1-10)	RPN	Mitigation
BLE PHY transceiver	Receives unauthenticated throttle command	Motor accelerates without rider input	9	4	8	288	Mutual authentication (LE Secure Connections P-256), session HMAC, monotonic counter
BLE pairing logic	Accepts MITM attack (KNOB CVE-2019-9506)	Attacker substitutes throttle command	9	3	7	189	LE SC + Numeric Comparison, reject Legacy Pairing < BLE 4.2
Motor controller command parser	Trusts BLE payload without origin check	Same as above	9	5	6	270	Plausibility check: throttle command must match physical Hall sensor reading within Δ = 10% per ISO 26262-9 § 6.4.5
Motor controller firmware	Race condition in interrupt handler	Glitch sets throttle to max for 1 cycle	8	2	9	144	MISRA C:2023 Rule 8.13 (interrupt-safe shared variables), formal verification of state machine
Watchdog timer	Stuck-on (never expires)	Failed firmware cannot be detected	9	2	5	90	Windowed watchdog (early + late deadline), external supervisor IC (TI TPS3702)
Current sense	Single-channel fault → no detection of overcurrent	Motor draws > nominal, heat damage	7	3	6	126	Dual current shunt + ADC, comparator over-current latch hardware-side

RPN priority threshold для дій (industry baseline): RPN ≥ 100 — потребує immediate mitigation; RPN ≥ 50 — потребує review; RPN < 50 — accept residual risk. У цьому FMEA-row 6 з 6 виходять > 100 → всі 6 mitigation actions обов’язкові для ASIL B claim.

7. FTA worked example: wheel lock at speed

Fault Tree Analysis (IEC 61025:2006) — top-down метод, який починається з top event (наприклад, “Wheel locks at speed > 25 km/h, rider thrown forward”) і будує дерево всіх можливих причинних послідовностей через AND/OR gates.

Top event: Front wheel locks at speed > 25 km/h → rider thrown forward → S3 fatality risk.

TOP: Wheel locks at speed > 25 km/h
 |
 OR
 +-- Brake actuator commanded > 100% lever travel
 |    AND
 |    +-- Rider applies brake fully (intentional, not a fault)
 |    +-- Wheel-lock not prevented by ABS  [if equipped]
 |
 +-- Bearing seizure
 |    OR
 |    +-- Bearing infant mortality (Weibull β < 1, ~5% in first 100 h)
 |    +-- Water ingress + corrosion (covered у IP article)
 |    +-- Overload from impact (pothole) → race deformation
 |
 +-- Hub motor lock-up (electronic)
 |    OR
 |    +-- MOSFET stuck-on phase A + phase B short → 3-phase short → regen torque > braking
 |    +-- Firmware bug: regen brake command without ramp limiter → instant max torque
 |    +-- BMS comm fault → motor controller misreads voltage → over-current
 |
 +-- Tire failure
      OR
      +-- Sudden deflation (pinch flat, puncture)
      +-- Tire/rim separation (under-inflation + lateral load)
      +-- Tread separation (manufacturing defect, age fatigue)

Minimal cut sets (MCS) для top event (комбінації базових подій, які достатньо для top event):

• MCS-1: {Rider brake fully + No ABS} — frequent, but intentional, not a “fault”
• MCS-2: {Bearing seizure} — single point of failure, requires mitigation
• MCS-3: {MOSFET A stuck-on AND MOSFET B short} — dual failure, λ_combined ≈ 10⁻¹⁰ per hour (acceptably rare)
• MCS-4: {Firmware regen bug} — single firmware fault, requires ASIL-graded software process
• MCS-5: {Tire deflation} — depends on tire engineering (covered у tire-engineering article)

FTA result: top-event probability P_top ≈ Σ P(MCS_i). Якщо P_top > 10⁻⁶/h → not acceptable for SIL 2 high-demand; необхідна додаткова mitigation (наприклад, додати ABS — pulse braking при detected wheel lock per ISO 11838 motorcycle ABS analogy).

8. FMEDA, PFH_D, SFF, HFT — quantitative architecture metrics

FMEDA (Failure Modes, Effects, and Diagnostic Analysis) — комбінація FMEA + analysis on-line diagnostic coverage. Виходом є λ (загальна failure rate) розкладена на 4 категорії:

• λ_S — safe failures (відмови, що ведуть до безпечного стану — наприклад, fuse opens)
• λ_SD — safe detected (безпечні, виявлені BIST)
• λ_DU — dangerous undetected (небезпечні, невиявлені — найгірша категорія)
• λ_DD — dangerous detected (небезпечні, виявлені online — система переходить у safe state)

Тоді обчислюється:

$$SFF = \frac{\lambda_S + \lambda_{DD}}{\lambda_{total}}$$

$$PFH_D = \lambda_{DU} \quad \text{(high-demand mode, IEC 61508-6 Table 6)}$$

$$PFD_{avg} = \frac{\lambda_{DU} \times T_1}{2} \quad \text{(low-demand mode, T_1 = proof test interval)}$$

Architectural constraint table (IEC 61508-2 Table 3, Type B subsystems with software-based control, complex digital):

SFF	HFT = 0	HFT = 1	HFT = 2
< 60%	not allowed	SIL 1	SIL 2
60% … 90%	SIL 1	SIL 2	SIL 3
90% … 99%	SIL 2	SIL 3	SIL 4
≥ 99%	SIL 3	SIL 4	SIL 4

For e-scooter motor controller — typical FMEDA output (similar до автомобільної інверторної ECU per ISO 26262-11:2018 semiconductor annex):

• λ_total ≈ 200 FIT (200 failures per 10⁹ h, IEC 61709 reference conditions T = 40°C)
• DC ≈ 90% (з watchdog + current monitor + temperature monitor + lockstep CPU)
• SFF ≈ 92% → with HFT = 1 (dual-channel current sense) → SIL 2 claim allowed
• PFH_D ≈ 0.1 × 200 × 10⁻⁹ = 2 × 10⁻⁸ /h → within ASIL B target

9. EN 17128:2020 Annex G PLEV functional safety requirements

EN 17128:2020 “Personal light electric vehicles (PLEV) — Bicycles and self-balancing vehicles intended for the transport of persons and/or goods” — гарманізований європейський стандарт для CE-marking PMD на ринку ЄС. Annex G “Functional safety considerations” встановлює якісні (не quantitative) вимоги:

Annex G clause	Requirement	Compliance evidence
G.2.1	Risk assessment per ISO 12100	Documented HARA report
G.2.2	Use of harmonized standards (ISO 13849-1, IEC 62061) where applicable	Cross-reference list
G.3.1	Brake controller failure shall not result in unintended acceleration	Test report + FMEA
G.3.2	Throttle stuck-on shall trigger safe state within 500 ms	HIL test report
G.3.3	Power-on shall require positive user confirmation (not auto-restart)	Functional test
G.3.4	Brake activation shall override throttle при будь-якій помилці у throttle channel	Functional + HIL test
G.4.1	Software shall follow established lifecycle (V-model, ISO 26262-6 or equivalent)	Process audit + traceability matrix
G.4.2	Critical parameters (max speed, max accel) shall be stored у protected memory area	Memory protection test
G.5.1	Operating temperature range shall be declared	Datasheet + test report

Note: EN 17128 Annex G не містить quantitative SIL/PL targets — це process-based compliance. Для product liability (EU Directive 85/374/EEC) реальний baseline — це ISO 26262 ASIL B для controlled subsystems і ISO 13849-1 PLr d для brake/throttle by-wire, незалежно від EN 17128 minimum floor.

10. Software safety: V-model, MISRA C:2023, formal methods

Software не має “λ_dangerous” як hardware — software відмови detерміністичні, але імовірнісно проявляються через input space coverage. Тому software safety будується через process rigour, що зростає з SIL/ASIL/PL:

SIL / ASIL / PL	Required coverage	Coding subset	Verification methods
SIL 1 / ASIL A / PLr b	Statement coverage 100%	MISRA C:2023 mandatory rules	Code review + unit test
SIL 2 / ASIL B / PLr c	Branch coverage 100%	MISRA C:2023 mandatory + advisory	Code review + static analysis (Polyspace/LDRA/Helix QAC) + unit + integration
SIL 3 / ASIL C / PLr d	MC/DC coverage 100% (Modified Condition/Decision Coverage)	MISRA C:2023 strict + bounded language subset	Static analysis + structural coverage + abstract interpretation (Astrée) + model-based testing
SIL 4 / ASIL D / PLr e	MC/DC + formal verification of safety-critical units	SPARK Ada or Frama-C ACSL annotated C	Theorem proving (Coq/Isabelle) + model checking (TLA+/SPIN) + N-version programming

V-model phases (IEC 61508-3:2010 § 7, ISO 26262-6:2018 Figure 1):

1. Requirements (REQ) ↔ Acceptance test (validation)
2. Architecture ↔ System test (integration validation)
3. Module design ↔ Integration test
4. Detailed design ↔ Unit test
5. Implementation (coding)

Кожна вертикальна пара має bidirectional traceability (REQ → design → code → test → result), документована у tool типу IBM DOORS, Polarion ALM, або JAMA Connect. Для e-scooter ASIL B firmware це означає: ~150-300 REQ items, ~50-80 architecture elements, ~200-400 code modules, ~2 000-4 000 unit test cases, ~500-1 000 integration test cases, ~50-150 acceptance test cases.

MISRA C:2023 (175 rules + 47 directives) — наприклад, Rule 11.3 (“A cast shall not be performed between a pointer to object type and a pointer to a different object type”) виключає тип-небезпечні касти, які могли б корумпувати safety-critical state. Static-analysis tool типу Polyspace Code Prover чи Helix QAC автоматично перевіряє compliance і генерує certified deviation report для unavoidable violations.

11. SOTIF (ISO/PAS 21448:2022) — Safety of Intended Functionality

Класична FuSa (IEC 61508 + ISO 26262) обмежена до fault-driven hazards — небезпеки, що виникають через відмову компонента. SOTIF (Safety Of The Intended Functionality) — extension, що покриває scenario-driven hazards: коли система працює за специфікацією, але сама специфікація недостатня для всіх real-world сценаріїв.

Класичний приклад SOTIF: ADAS-сенсор виявляє пішоходів за пороговим contour matching; у сценарії, де пішохід тримає велике дзеркало, contour viralно distorts, і алгоритм пропускає detection. Не fault — це edge case у operational design domain (ODD).

Для e-scooter SOTIF-сценарії:

• SOTIF-1: Throttle deadband 5% — у scenario, де rider stands on inclined ramp і just touches throttle, scooter starts moving when rider expects stationary
• SOTIF-2: Regen brake autoshut-off при battery 100% SoC — у scenario, де rider descends long hill з фulli charged battery, regen відключається, fading mechanical brake → loss of effectiveness
• SOTIF-3: BLE auto-reconnect to last paired phone — у scenario, де rider’s phone is stolen and re-paired by thief next session, unauthenticated throttle command accepted
• SOTIF-4: Wheel-slip threshold trigger на гладкому покритті — алгоритм detects slip і знижує power, але rider хоче full power for traction on wet leaf → unexpected behavior

SOTIF-mitigation спирається на 4 стратегії (ISO/PAS 21448 § 7):

1. Improve sensing (додаткові sensors / fusion)
2. Improve algorithm (training data, edge case enumeration)
3. Constraint ODD (документувати, де система не призначена для роботи)
4. Improve HMI (warn rider про ризики)

12. Verification & validation: HIL, fault injection, ALT

Hardware-in-the-loop (HIL) testing — bench, що симулює physical environment (motor as electrical load, brake as hydraulic actuator) і feeds real-time stimuli у ECU under test. Для motor controller HIL — це bench з dyno-machine + 3-phase inverter emulator + brake load emulator + ADC stimulus injector. Tools: NI VeriStand + dSPACE SCALEXIO + Vector CANoe + ETAS LABCAR.

Fault injection — навмисне впровадження відмов:

• Hardware-level: SWIFI (Software Implemented Fault Injection — bit-flip RAM via debugger), pin-level (cut/short to GND/V+ via DUT-specific test fixture), supply-level (sag/surge per IEC 61000-4-29)
• Software-level: random bit-flips у memory image, message corruption на CAN/BLE bus, scheduling pre-emption test
• Standard: ISO 26262-11:2018 § 4.6 “Fault injection at HW-SW interface”

Accelerated Life Testing (ALT):

• HALT (Highly Accelerated Life Test, Greg Hobbs Hobbs Engineering) — step-stress thermal (−80°C to +200°C з sweep ≥30°C/min) + 6-DOF vibration (≥50 Grms) для виявлення design weaknesses
• HASS (Highly Accelerated Stress Screen) — production-line screen, що відсіює infant mortality units
• Arrhenius equation для thermal aging: AF = exp(Ea/k × (1/T_use − 1/T_test)), з activation energy Ea = 0,7 eV для типового electronics → 10°C → 2× life impact
• Coffin-Manson model для thermal cycling fatigue: N_f ∝ (ΔT)⁻ⁿ, n = 2-4 для solder joints

13. Real incidents and recalls: e-scooter safety timeline 2018-2026

8-row real-incidents timeline, що ілюструє наслідки відсутності функціональної безпеки у consumer PMD-сегменті (0 russian sources, всі англомовні primary records):

Дата	Інцидент / Recall	Підсистема	Корінна причина	Регуляторна дія
2018-06	Boosted Board Stealth fire (multiple reports)	BMS thermal runaway	Single-MOSFET BMS without redundant overcurrent + insufficient thermistor density	CPSC.gov VIN-Number recall #18-263, cpsc.gov
2019-04	Lime Generation 3 brake auto-engagement at speed (~30 reports)	Brake actuator	Firmware bug — moisture sensor false positive triggered E-brake at 25 km/h on dry surface	Lime worldwide firmware push 2019-04-08, ~3 000 units field service per techcrunch.com/2019/04/08
2019-06	Xiaomi M365 BLE anti-lock bypass (Zimperium 2019)	Motor controller + BLE	No authentication on BLE throttle commands	Xiaomi M365 firmware OTA 2019-08, but units sold before remain vulnerable; covered у cybersecurity-engineering.md
2019-09	Skip Pro fleet fire San Francisco (1 device burst into flames in user’s apartment)	BMS	Manufacturing defect — cell separator pierced by stray welding bead	SkipDelivery-related news + CPSC.gov initial review 2019-10; Skip subsequently bankrupt 2020-08
2020-01	Ninebot ES2 throttle creep при cold start	Throttle position sensor	Hall sensor temperature drift outside compensation table	Segway-Ninebot firmware 1.5.5 OTA push 2020-02
2020-08	Apollo Pro firmware bug — motor freewheel при regen	Motor controller firmware	Race condition у regen-brake state machine при rapid throttle-to-brake transition	Apollo firmware 2.0.4 OTA push 2020-09
2021-03	Bird Two rear-wheel hub crack (3+ reports of catastrophic failure at speed)	Wheel/hub assembly	Aluminum hub fatigue under cyclic load — undersized fillet radius	Bird worldwide retrofit campaign 2021-06 з replacement hubs
2022-11	Tier Wallet edition motor-stuck при wet conditions	Motor controller	Water ingress IP-rated only IPX4, but city use exceeded spec → corroded MOSFET drive line	Tier German fleet pulled for refurbishment Q4 2022, IPX5 minimum added to next-gen spec

Кожен з цих 8 інцидентів можна було б детектувати або mitigated через FuSa-процес: BMS Boosted — FMEDA on single-point-of-failure + dual-channel OCP; Lime brake — HARA + FTA з MOSFET ставив-би-в-safe-state логіку; Ninebot throttle — temperature plausibility check; Apollo regen — formal verification of state machine. Жоден з виробників не публікував SIL/ASIL claim на час інциденту → industry baseline був “best effort” без quantitative target.

14. Mitigation matrix: 6 типових технік + cost-benefit

Mitigation	Subsystem	Reduces (specific failure mode)	Effective for SIL/ASIL	Cost-impact per unit
Dual-channel current sense + cross-check	Motor controller	MOSFET stuck-on undetected (DC: 60% → 95%)	up to ASIL B / SIL 2	$1-3 (extra shunt + ADC channel)
Watchdog timer (windowed) + external supervisor IC	Motor controller, BMS	Firmware lockup, infinite loop	up to SIL 2	$0.50-2 (TI TPS3702, MAX16135)
2oo2 voting Hall sensors з diverse manufacturing	Throttle, motor commutation	Single sensor drift, short, open	up to ASIL B / SIL 2	$1-2 (second Hall + diverse vendor)
Lockstep CPU (ARM Cortex-R5F, TI Hercules TMS570)	Motor controller MCU	CPU bit-flip, single-event upset	up to ASIL D / SIL 3	$5-15 (vs single-core MCU)
Hardware overcurrent comparator (HW-only path)	BMS, motor controller	Slow firmware response to over-current	up to ASIL D / SIL 3	$0.50-1 (comparator IC + reference)
Brake-priority lockout (HW interrupt → throttle clamp)	Brake + throttle integration	Throttle hold during emergency brake	up to ASIL D / SIL 3	$0 (firmware-only) + ~50-100 lines code

Cost ranges based on supplier quotes 2024-2026 (Digi-Key, Mouser, Octopart, JLCPCB BOM). Total mitigation budget для ASIL B motor controller — typically $10-25 per unit, що додає 5-12% до BOM cost mid-range PMD ($200-500 retail).

15. DIY safety check (8-step) + remediation (6-step)

8-step DIY safety check (без spec. obladnannia, для регулярного володіння):

1. Brake actuator integrity — обидва гальма (front + rear) повинні стопити окремо: підніми задню колесо, прокрути, натисни задню гальма — колесо повинне зупинитись < 1 s; те саме для переднього.
2. Throttle deadband + ramp — на нерухомому самокаті ввімкни, відпусти руки з throttle, нічого не повинно крутитись. Натисни throttle 10% — мотор повинен почати з помітною затримкою (deadband + ramp ≥ 200 ms; instant response = небезпечний firmware).
3. Power-on self-test — при ввімкненні дисплей повинен показати full segment test (всі LCD-segments на 1 s) або BIST-індикатор; missing self-test = no fault detection.
4. Brake-overrides-throttle test — на нерухомому самокаті, натисни і утримуй throttle 30%, потім натисни брейк-лівер; мотор має миттєво вимкнутись (cut < 100 ms).
5. Battery thermal check — після 30 хв їзди торкнись пакета батареї тильною стороною долоні (без рукавички): > 50°C = warning, > 60°C = stop usage, ймовірно несправний thermistor чи BMS thermal management.
6. BLE auto-reconnect behavior — вимкни phone, ввімкни самокат і одразу залиш — він НЕ повинен auto-reconnect до невідомого ВТ-пристрою; reconnect prompt має вимагати active confirmation на phone.
7. Headlight + rear light functional — обидва повинні працювати при ввімкненні; перевір окремий day-running mode (якщо є).
8. Speed limiter check — на безпечній прямій ділянці перевір, що max speed відповідає декларованій (не +10% drift через worn throttle); accelerated past limit = controller calibration issue.

6-step DIY remediation (коли check fail):

1. Brake lever travel — більше 50% travel до stop = повітря у гідравлічній лінії (bleeding required, див. brake-bleeding-and-pad-care.md) або кабель механічного гальма потребує заміни.
2. Throttle instant-response — заміни throttle на OEM-spec (Hall + ramp filter); never trust aftermarket “performance throttle” без datasheet.
3. Missing power-on self-test — firmware update до latest version; якщо вендор не публікує changelog с safety items, перейди до іншої моделі.
4. Brake не override throttle — потрібен hardware fix (свапнути cable до bra-lever sensor input), не firmware fix; ризик SOTIF-2 scenario.
5. Battery > 60°C — припини використання до visit-сервісу; зніми BMS, перевір thermistor placement (повинен бути в дотику до cell groups, не до casing).
6. No BLE auth — встанови physical kill-switch на BLE module power line (vendor може мати aftermarket “BLE disable” doc); covered у cybersecurity-engineering.md DIY remediation list.

16. Industry shift 2020→2026 + 10-point recap

Industry shift 2020→2026:

• 2020: ASIL/SIL/PL не згадані у жодному consumer PMD specification sheet. EN 17128 не вимагає quantitative targets. Recall rate per CPSC.gov ~ 12 incidents/year на e-scooter сегмент.
• 2022: Перші великі флот-оператори (Lime, Tier, Bird) починають публічно цитувати ISO 26262 alignment у safety reports. Tier publishes “Safety by Design” white paper з FMEA references.
• 2024: Bosch eAxle для e-scooter (Bosch SmartPedal subsidiary) сертифікований за ISO 26262 ASIL B as ECU supplier. UL 2272 update додає functional safety requirements analogous to ISO 13849.
• 2026: EN 17128 під review для додавання quantitative SIL/PL targets (CEN/TC 354 WG 11 draft 2026-Q3); EU CRA (Cyber Resilience Act 2024/2847) explicitly cross-references EN 17128 functional safety annex; expected effective date 2027-12-11.

Recall rate trend (CPSC.gov + RAPEX EU Safety Gate aggregated, 2020-2025): ~12 → ~5 fire/uncontrolled-acceleration incidents/year/major-OEM, з різким падінням після 2023 — корелює з widespread adoption MISRA C compliant firmware і dual-channel current sense.

10-point recap:

1. Функціональна безпека — доказова дисципліна: кожна safety claim мусить мати quantitative basis (λ, PFH_D, SFF, HFT), не суб’єктивну впевненість.
2. Скейл S × E × C → ASIL/SIL/PL алокується кожній safety function окремо, не системі в цілому; e-scooter brake → ASIL D, display → ASIL A.
3. Risk reduction equation: R_residual = R_unmitigated / RRF, з ALARP-принципом для не-quantifiable residual.
4. FMEA (bottom-up) і FTA (top-down) — компліментарні; FMEA знаходить single-point failures, FTA знаходить interactions / common causes.
5. FMEDA додає diagnostic coverage: λ розкладається на λ_S / λ_SD / λ_DD / λ_DU, з SFF + HFT як architectural constraint.
6. EN 17128:2020 Annex G — обов’язковий floor для CE-marking PLEV, але процес-based, без quantitative targets → industry voluntary baseline = ISO 26262 ASIL B / ISO 13849-1 PLr d.
7. Software safety — process rigour (V-model + MISRA C:2023 + MC/DC coverage + formal methods для SIL 4 / ASIL D), не probabilistic.
8. SOTIF (ISO/PAS 21448) — extension класичної FuSa для scenario-driven hazards, де specification сама недостатня.
9. Verification stack — HIL + fault injection + HALT/HASS + Arrhenius/Coffin-Manson для життєвого циклу.
10. Real incidents 2018-2022 (Boosted fire, Lime brake bug, Xiaomi BLE, Ninebot throttle, Bird hub) — кожен можна було б детектувати у HARA + FMEDA + STPA, але виробники не публікували quantitative claims. Industry shift 2024-2026 — ISO 26262 alignment стає implicit baseline.

NVH (EB) і функціональна безпека (ED) разом завершують first sextet cross-cutting infrastructure axes — шість, що описують не окрему підсистему, а спосіб встановлення інженерного контракту на якусь властивість, що пронизує весь апарат: joining (DT), heat-dissipation (DV), interference-mitigation (DX), interconnect-trust (DZ), acoustic-vibration-emission (EB), safety-integrity (ED). У наступних інженерних циклах ми додамо HMI/UX (EN ISO 9241-110/171), lifecycle/EoL (WEEE 2012/19/EU + EU Battery Reg 2023/1542), environmental robustness (IEC 60068-2 climatic series) як кандидатів на сьому, восьму і дев’яту cross-cutting axes.