E-scooter functional safety engineering: safety integrity as the sixth cross-cutting infrastructure axis — IEC 61508:2010 (E/E/PE safety-related systems, SIL 1-4) + ISO 26262:2018 (automotive FuSa, ASIL A-D) + ISO 13849-1:2023 (safety-related parts of machinery, PLr a-e, Cat B/1/2/3/4) + IEC 62061:2021 (SIL CL for machinery 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

Across the engineering guide series we covered the lithium-ion battery with BMS and thermal runaway intro, the brake system, the motor and controller, suspension, tires, lighting and visibility, the frame and fork, display and HMI, the SMPS CC/CV charger, connector + wiring harness, IP protection, bearings with ISO 281 L10, the stem and folding mechanism, the deck, handgrip + lever + throttle, the wheel as an assembly, bolted-joint engineering as a joining-axis, thermal management as the heat-dissipation cross-cutting axis, EMC/EMI as the interference-mitigation cross-cutting axis, cybersecurity as the interconnect-trust cross-cutting axis, and NVH as the acoustic-vibration-emission cross-cutting axis. These 22 engineering axes described individual subsystems, joining methods, heat dissipation, electromagnetic coexistence, trust establishment, and acoustic/vibration emission — but none of them described how much each subsystem is allowed to fail: what probability of a dangerous failure is acceptable, how to quantify it, how to reduce it, and how to prove the residual risk is below the regulatory threshold.

A modern e-scooter is a collection of 5+ safety-critical subsystems: (a) the motor controller, whose “stuck-open” MOSFET failure causes unintended acceleration; (b) the brake actuator (mechanical lever + hydraulic line / disc + electronic regen), whose “loss-of-stopping-power” failure precludes stopping the motion; (c) the throttle position sensor (Hall effect / potentiometer), whose drift triggers spontaneous acceleration; (d) the BMS (Battery Management System), whose “fail-overcurrent” or “fail-overtemperature” failure leads to thermal runaway and fire; (e) the display HMI, whose “frozen screen” or “wrong-info” mode hides critical state from the rider. Each of these failures can cause serious injury or fatality, so functional safety as an engineering discipline quantifies how often these failures can occur and how to design the system so the dangerous-failure probability is below an allocated target (e.g. < 10⁻⁶ dangerous failures per hour for SIL 2 high-demand mode per IEC 61508-1 § 7.6.2.9 Table 3).

This is the twenty-third engineering-axis deep-dive in the guide series — and the sixth cross-cutting infrastructure axis (parallel to fastener-as-joining, thermal-management-as-heat-dissipation, EMC/EMI-as-interference-mitigation, cybersecurity-as-interconnect-trust, and NVH-as-acoustic-vibration-emission). Functional safety describes the means of establishing an acceptable level of dangerous failures, which is present in every preceding axis: BMS with ASIL-rated firmware, brake actuator with PLr-d redundancy, motor controller with a safety MCU lockstep CPU, throttle with 2oo2 voting on dual Hall sensors, display with an ISO 26262-compliant graphics stack. The job of FuSa engineering is to quantify the hazard rate (HARA), allocate the target SIL/ASIL/PL to each function, design hardware architecture with the required HFT and SFF, verify software per MISRA C:2023 and structural coverage, confirm via FMEA + FTA + FMEDA that the PFD or PFH fits within the allocated budget, and demonstrate compliance through a safety case (GSN notation).

PLEV (Personal Light Electric Vehicle) context: an e-scooter is not in the scope of ISO 26262 (passenger cars and light trucks ≤3.5 t per § 1 “Scope” 2018 edition), not in the scope of IEC 61511 (process industry safety instrumented systems), partially covered by IEC 62061 (machinery), formally covered by EN 17128:2020 Annex G (PLEV functional safety requirements, but qualitatively, without quantitative SIL/PL targets), and by analogy uses IEC 61508 (the foundational E/E/PE safety standard for any electronic/programmable protection). So the industry baseline is voluntary compliance with ASIL B/B+ for the motor controller (by analogy to ISO 26262-compliant ECU suppliers like Bosch, Continental, Nidec), ISO 13849-1 PLr d for brake-by-wire and throttle-by-wire (by analogy to machinery safety), and EN 17128:2020 Annex G as the mandatory floor for CE-marking in the EU market.

1. Why functional safety is a distinct cross-cutting axis

Functional safety is not just “won’t fail”. It is a system in which every element has a quantified dangerous-failure probability:

FuSa element	What it captures	Governing standard
Hazard analysis and risk assessment (HARA)	List of possible hazards with severity (S0-S3) × exposure (E0-E4) × controllability (C0-C3) → ASIL A/B/C/D or QM	ISO 26262-3:2018 § 6 “Hazard analysis and risk assessment”, ISO 12100:2010 machinery risk
Safety integrity level allocation	Target safety level per function — 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	Configuration 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; with MISRA C:2023 coding subset, MC/DC coverage for 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 = failures per 10⁹ h), MTBF, PFD (low-demand) or 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)	Fraction of dangerous failures detected by online diagnostics (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)	Fraction of safe (S) + dangerous-detected (DD) failures out of total — SFF = (λ_S + λ_DD) / λ_total	IEC 61508-4:2010 § 3.6.15, ISO 26262-5:2018 § 8.4.6
Hardware fault tolerance (HFT)	Number of simultaneous hardware faults the system tolerates without losing the safety function	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	A structured argument (GSN — Goal Structuring Notation) that residual risk ≤ tolerable per ALARP	UK MoD Defence Standard 00-56 Part 1, GSN Community Standard v3, ISO 26262-2:2018 § 6.4.5

Each of these 10 elements is quantified: hazard rate from PHA, target SIL/ASIL/PL from a risk graph, λ from IEC 61709, DC from diagnostic coverage analysis, SFF from architectural constraints, PFH_D from FMEDA. If even one element is not quantified — the system cannot demonstrate compliance, regardless of the developer’s subjective confidence. That is the key distinction between FuSa and “best effort” engineering: an evidence-based discipline.

2. Risk reduction equation, ALARP, tolerable risk

The base equation of functional safety (IEC 61508-1 § 7.4.4):

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

where RRF (Risk Reduction Factor) is the risk-reduction factor due to the safety function. For low-demand mode RRF = 1 / PFD_avg; for 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 — the acceptable probability of a dangerous event per person per year. Industry benchmarks (HSE UK R2P2 2001, EN 50126-2 railway):

• Intolerable (verboten): > 10⁻³ fatalities/person/year — mandatory reduction
• ALARP zone: 10⁻³ … 10⁻⁶ — reduction “As Low As Reasonably Practicable”
• Broadly acceptable: < 10⁻⁶ — no further action

The ALARP principle (As Low As Reasonably Practicable, HSE UK 2001) requires reducing risk down to the point at which further reduction becomes disproportionate to the benefit (cost-benefit analysis). For an e-scooter, that threshold is determined by the market: if each additional 10⁻⁷ reduction in hazard rate costs > $50 per unit, the manufacturer can argue that further reduction is “not reasonably practicable”. The HSE Q-CDF (Quantitative Cost-Disproportion Factor) is typically 1-10 for individual risks.

GAMAB (Globalement Au Moins Aussi Bon, “globally at least as good”) and MEM (Minimum Endogenous Mortality, ~2 × 10⁻⁵/person/year) — alternative frameworks from the French and German regulatory traditions, which set tolerable risk as no worse than existing equivalent systems (GAMAB) or below the natural minimum mortality rate (MEM, EN 50126-2 Annex C).

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

Four standards use different safety-integrity scales, but all are tied to probability of dangerous failure per hour (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 (for D without single fault)	d	SIL CL 3	10⁻⁸ … 10⁻⁷	10 000-100 000
SIL 4	ASIL D (for extreme uncontrollable hazards)	e	— (≤ SIL CL 3)	10⁻⁹ … 10⁻⁸	100 000-1 000 000

Typical e-scooter allocations (by analogy to automotive supplier practice — Bosch / Continental / Nidec 2022-2026):

• Motor controller throttle-stuck → unintended acceleration: ASIL B (S2 serious injury × 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 — highest level)
• Throttle position drift: ASIL B (S2 × E3 × C2 = B)
• BMS thermal runaway / overcurrent: ASIL C (S3 × E2 × C2 = C; broader citations reference UN R100, EN 50604-1)
• Display HMI critical info loss (speed, battery SoC, error indicator): ASIL A (S1 × E3 × C2 = A; informative, not actuation)
• Headlight fail-dark during night-time risk: ASIL B (S2 × E2 × C2 = B; aligns with UK PAS 1881 categorization)

The alternative formal allocation via ISO 13849-1 risk graph (Annex A, fig. A.1) for brake-by-wire e-scooter — S2 (serious, reversible injury) × F2 (frequent exposure) × P2 (uncontrollable) → PLr d. For throttle-by-wire — S1 × F2 × P2 → PLr c. For motor controller short-stuck — S2 × F2 × P1 → PLr c.

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

The first step of functional safety is identifying all possible hazardous events. Industry practice uses 4 methodologies (integrated into ISO 26262-3 and IEC 61508-1):

Method	Approach	Best for	Standard
PHA (Preliminary Hazard Analysis)	Brainstorm session with a hazard-class checklist (mechanical, electrical, thermal, chemical, ergonomic) at early concept design	Initial concept phase	MIL-STD-882E:2012 § 4.4, AIChE PHA Best Practices
HAZID (Hazard Identification)	Structured workshop with identification team (operator + designer + safety engineer + maintenance) and domain-specific checklist	System level, before architecture	API RP 14J, DNV-OS-A101
HAZOP (Hazard and Operability)	Deviation analysis from project intent via guide-words (NO, MORE, LESS, AS WELL AS, REVERSE, OTHER) on each system node	Detailed design phase, process plants	IEC 61882:2016
STAMP / STPA (Systems-Theoretic Process Analysis)	Modern systems-theoretic method (Leveson MIT 2012+) modeling control loops and identifying UCAs (Unsafe Control Actions)	Complex adaptive systems with software-intensive control loops	Leveson “Engineering a Safer World” MIT Press 2012, STPA Handbook 2018

E-scooter STPA example (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 for UCA-1: (a) BLE remote injection (covered in cybersecurity-engineering); (b) Hall sensor short to V_supply; (c) EMC pickup on ADC input (covered in emc-emi-engineering); (d) firmware race condition; (e) memory bit-flip from cosmic ray / alpha particle.

5. Hazard-by-subsystem matrix

The six safety-critical e-scooter subsystems and their typical hazardous events:

Subsystem	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 in parallel, brake-light status indicator
Throttle position sensor	Hall sensor short / drift → input ramp from 0 to max	S2 × E3 × C2	B	2oo2 voting on dual Hall sensors with 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 — rider unaware of critical state	S1 × E3 × C2	A	Watchdog refresh, dedicated error LED, audible buzzer fallback, redundant minimal LCD
Lighting (headlight + rear)	Fail-dark in night-time conditions	S2 × E2 × C2	B	Redundant LED arrays, hot-swap fallback, day-running light independent, ECE R148 / SAE J583 compliance

The S × E × C scale per ISO 26262-3:2018 Tables 1-3:

• S (Severity): S0 nothing / S1 light and moderate injuries / S2 severe and potentially life-threatening (survival probable) / S3 life-threatening (survival uncertain) or fatality.
• E (Exposure): E0 incredibly unlikely / E1 very low (< 1 % operating time) / E2 low (1-10 %) / E3 medium (10-50 %) / E4 high (> 50 %).
• C (Controllability): C0 controllable in general / C1 simply controllable / C2 normally controllable (> 90 % of drivers) / C3 difficult to control or uncontrollable (< 90 %).

6. FMEA worked example: BLE throttle injection

Failure Mode and Effects Analysis (IEC 60812:2018) — a bottom-up method that for each component enumerates possible failure modes, effects, probability (O), severity (S), detectability (D), and computes RPN = O × S × D.

Scenario: BLE display sends a throttle-injection command to the motor controller (a CVE-class vulnerability documented in cybersecurity-engineering).

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 for action (industry baseline): RPN ≥ 100 — requires immediate mitigation; RPN ≥ 50 — requires review; RPN < 50 — accept residual risk. In this FMEA, 6 out of 6 rows exceed 100 → all 6 mitigation actions are mandatory for an ASIL B claim.

7. FTA worked example: wheel lock at speed

Fault Tree Analysis (IEC 61025:2006) — a top-down method that begins with a top event (e.g. “Wheel locks at speed > 25 km/h, rider thrown forward”) and builds a tree of all possible causal sequences through 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 in 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) for the top event (combinations of base events sufficient for the 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 in tire-engineering article)

FTA result: top-event probability P_top ≈ Σ P(MCS_i). If P_top > 10⁻⁶/h → not acceptable for SIL 2 high-demand; additional mitigation is required (e.g. add ABS — pulse braking upon 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) — a combination of FMEA + online diagnostic coverage analysis. The output is λ (total failure rate) broken down into 4 categories:

• λ_S — safe failures (failures that lead to a safe state — e.g. fuse opens)
• λ_SD — safe detected (safe, detected by BIST)
• λ_DU — dangerous undetected (dangerous, not detected — the worst category)
• λ_DD — dangerous detected (dangerous, detected online — system transitions to safe state)

Then we compute:

$$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 an e-scooter motor controller — a typical FMEDA output (similar to an automotive inverter 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 % (with 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 the 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” — the harmonized European standard for CE-marking PMDs in the EU market. Annex G “Functional safety considerations” establishes qualitative (not quantitative) requirements:

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 on any error in the throttle channel	Functional + HIL test
G.4.1	Software shall follow an 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 in a protected memory area	Memory protection test
G.5.1	Operating temperature range shall be declared	Datasheet + test report

Note: EN 17128 Annex G does not contain quantitative SIL/PL targets — it is process-based compliance. For product liability (EU Directive 85/374/EEC) the real baseline is ISO 26262 ASIL B for controlled subsystems and ISO 13849-1 PLr d for brake/throttle by-wire, regardless of the EN 17128 minimum floor.

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

Software does not have a “λ_dangerous” the way hardware does — software failures are deterministic but probabilistically manifest via input-space coverage. So software safety is built through process rigour that grows with 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)

Each vertical pair has bidirectional traceability (REQ → design → code → test → result) documented in a tool like IBM DOORS, Polarion ALM, or JAMA Connect. For an e-scooter ASIL B firmware this typically means: ~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) — e.g. Rule 11.3 (“A cast shall not be performed between a pointer to object type and a pointer to a different object type”) rules out type-unsafe casts that could corrupt safety-critical state. A static-analysis tool like Polyspace Code Prover or Helix QAC automatically checks compliance and produces a certified deviation report for unavoidable violations.

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

Classical FuSa (IEC 61508 + ISO 26262) is limited to fault-driven hazards — hazards arising from component failure. SOTIF (Safety Of The Intended Functionality) is an extension that covers scenario-driven hazards: when the system operates per specification, but the specification itself is insufficient for all real-world scenarios.

Classic SOTIF example: an ADAS sensor detects pedestrians via threshold contour matching; in a scenario where a pedestrian holds a large mirror, the contour is violently distorted and the algorithm misses the detection. Not a fault — it is an edge case in the operational design domain (ODD).

E-scooter SOTIF scenarios:

• SOTIF-1: throttle deadband 5 % — in a scenario where the rider stands on an inclined ramp and just touches the throttle, the scooter starts moving when the rider expects stationary
• SOTIF-2: regen-brake auto-shutoff at battery 100 % SoC — in a scenario where the rider descends a long hill with a fully charged battery, regen cuts out, fading the mechanical brake → loss of effectiveness
• SOTIF-3: BLE auto-reconnect to last paired phone — in a scenario where the rider’s phone is stolen and re-paired by a thief the next session, an unauthenticated throttle command is accepted
• SOTIF-4: wheel-slip threshold trigger on a smooth surface — the algorithm detects slip and reduces power, but the rider wants full power for traction on wet leaves → unexpected behavior

SOTIF mitigation builds on 4 strategies (ISO/PAS 21448 § 7):

1. Improve sensing (additional sensors / fusion)
2. Improve algorithm (training data, edge-case enumeration)
3. Constrain the ODD (document where the system is not intended to operate)
4. Improve the HMI (warn the rider about the risks)

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

Hardware-in-the-loop (HIL) testing — a bench that simulates the physical environment (motor as electrical load, brake as hydraulic actuator) and feeds real-time stimuli into the ECU under test. For a motor controller HIL — this is a bench with a dyno-machine + 3-phase inverter emulator + brake load emulator + ADC stimulus injector. Tools: NI VeriStand + dSPACE SCALEXIO + Vector CANoe + ETAS LABCAR.

Fault injection — deliberate introduction of failures:

• 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 in the memory image, message corruption on the CAN/BLE bus, scheduling preemption 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 with sweep ≥30 °C/min) + 6-DOF vibration (≥50 Grms) to surface design weaknesses
• HASS (Highly Accelerated Stress Screen) — a production-line screen that filters out infant-mortality units
• Arrhenius equation for thermal aging: AF = exp(Ea/k × (1/T_use − 1/T_test)), with activation energy Ea = 0.7 eV for typical electronics → 10 °C → 2× life impact
• Coffin-Manson model for thermal cycling fatigue: N_f ∝ (ΔT)⁻ⁿ, n = 2-4 for solder joints

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

An 8-row real-incidents timeline illustrating the consequences of absent functional safety in the consumer PMD segment (0 Russian sources, all English-language primary records):

Date	Incident / Recall	Subsystem	Root cause	Regulatory action
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 remained vulnerable; covered in cybersecurity-engineering
2019-09	Skip Pro fleet fire San Francisco (1 device burst into flames in a 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 on 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 during regen	Motor controller firmware	Race condition in regen-brake state machine during 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 with replacement hubs
2022-11	Tier Wallet edition motor-stuck in 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

Each of these 8 incidents could have been detected or mitigated via the FuSa process: BMS Boosted — FMEDA on single-point-of-failure + dual-channel OCP; Lime brake — HARA + FTA with the MOSFET would have driven the safe-state logic; Ninebot throttle — temperature plausibility check; Apollo regen — formal verification of the state machine. None of the manufacturers published a SIL/ASIL claim at the time of the incident → the industry baseline was “best effort” without a quantitative target.

14. Mitigation matrix: 6 typical techniques + 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 with 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 for an ASIL B motor controller is typically $10-25 per unit, adding 5-12 % to BOM cost on a mid-range PMD ($200-500 retail).

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

8-step DIY safety check (no special equipment, for regular owner cadence):

1. Brake actuator integrity — each brake (front + rear) must stop independently: raise the rear wheel, spin it, apply the rear brake — the wheel must stop in < 1 s; same for the front.
2. Throttle deadband + ramp — on a stationary scooter switch on, hands off the throttle, nothing should spin. Press throttle 10 % — the motor should start with a noticeable delay (deadband + ramp ≥ 200 ms; instant response = dangerous firmware).
3. Power-on self-test — at switch-on the display should show a full segment test (all LCD segments lit for 1 s) or a BIST indicator; missing self-test = no fault detection.
4. Brake-overrides-throttle test — on a stationary scooter, hold throttle at 30 % then squeeze the brake lever; the motor must immediately cut off (cut < 100 ms).
5. Battery thermal check — after 30 min of riding, touch the battery pack with the back of your hand (without a glove): > 50 °C = warning, > 60 °C = stop usage, likely faulty thermistor or BMS thermal management.
6. BLE auto-reconnect behavior — turn off the phone, switch on the scooter and walk away — it should NOT auto-reconnect to unknown BT devices; the reconnect prompt should require active confirmation on the phone.
7. Headlight + rear light functional — both must work at power-on; check for a separate day-running mode (if available).
8. Speed limiter check — on a safe straight section verify max speed matches the declared spec (no +10 % drift from worn throttle); accelerated past limit = controller calibration issue.

6-step DIY remediation (when a check fails):

1. Brake lever travel — more than 50 % travel before stop = air in hydraulic line (bleeding required, see brake-bleeding-and-pad-care) or mechanical brake cable needs replacement.
2. Throttle instant-response — replace the throttle with an OEM-spec part (Hall + ramp filter); never trust an aftermarket “performance throttle” without a datasheet.
3. Missing power-on self-test — firmware update to the latest version; if the vendor does not publish changelogs with safety items, switch to another model.
4. Brake not overriding throttle — needs a hardware fix (swap cable to brake-lever sensor input), not a firmware fix; this is the SOTIF-2 scenario risk.
5. Battery > 60 °C — stop usage until a service visit; remove BMS, check thermistor placement (must contact the cell groups, not the casing).
6. No BLE auth — install a physical kill switch on the BLE module power line (vendor may have an aftermarket “BLE disable” doc); covered in cybersecurity-engineering DIY remediation list.

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

Industry shift 2020→2026:

• 2020: ASIL/SIL/PL not mentioned in any consumer PMD specification sheet. EN 17128 does not require quantitative targets. CPSC.gov recall rate ~ 12 incidents/year on the e-scooter segment.
• 2022: First large fleet operators (Lime, Tier, Bird) begin to publicly cite ISO 26262 alignment in safety reports. Tier publishes a “Safety by Design” white paper with FMEA references.
• 2024: Bosch eAxle for e-scooter (Bosch SmartPedal subsidiary) certified to ISO 26262 ASIL B as an ECU supplier. UL 2272 update adds functional safety requirements analogous to ISO 13849.
• 2026: EN 17128 under review to add quantitative SIL/PL targets (CEN/TC 354 WG 11 draft 2026-Q3); the EU CRA (Cyber Resilience Act 2024/2847) explicitly cross-references the 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, with a steep drop after 2023 — correlating with widespread adoption of MISRA C compliant firmware and dual-channel current sense.

10-point recap:

1. Functional safety is an evidence-based discipline: every safety claim must have a quantitative basis (λ, PFH_D, SFF, HFT), not subjective confidence.
2. The S × E × C → ASIL/SIL/PL scale is allocated to each safety function independently, not to the system as a whole; the e-scooter brake → ASIL D, display → ASIL A.
3. Risk reduction equation: R_residual = R_unmitigated / RRF, with ALARP for the non-quantifiable residual.
4. FMEA (bottom-up) and FTA (top-down) are complementary; FMEA finds single-point failures, FTA finds interactions / common causes.
5. FMEDA adds diagnostic coverage: λ breaks down into λ_S / λ_SD / λ_DD / λ_DU, with SFF + HFT as the architectural constraint.
6. EN 17128:2020 Annex G is the mandatory floor for CE-marking PLEV, but process-based, with no quantitative targets → the industry voluntary baseline is ISO 26262 ASIL B / ISO 13849-1 PLr d.
7. Software safety is process rigour (V-model + MISRA C:2023 + MC/DC coverage + formal methods for SIL 4 / ASIL D), not probabilistic.
8. SOTIF (ISO/PAS 21448) extends classical FuSa for scenario-driven hazards where the specification itself is insufficient.
9. The verification stack — HIL + fault injection + HALT/HASS + Arrhenius/Coffin-Manson — covers the life cycle.
10. Real incidents 2018-2022 (Boosted fire, Lime brake bug, Xiaomi BLE, Ninebot throttle, Bird hub) — each could have been detected through HARA + FMEDA + STPA, but manufacturers did not publish quantitative claims. The 2024-2026 industry shift is making ISO 26262 alignment an implicit baseline.

NVH (EB) and functional safety (ED) together complete the first sextet of cross-cutting infrastructure axes — six axes that describe not an individual subsystem but a method of establishing an engineering contract on a property that pervades the whole device: joining (DT), heat-dissipation (DV), interference-mitigation (DX), interconnect-trust (DZ), acoustic-vibration-emission (EB), safety-integrity (ED). In subsequent engineering cycles we will add 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) as candidates for the seventh, eighth, and ninth cross-cutting axes.