Software and firmware engineering for embedded ECUs of an electric scooter as the 29th engineering axis: UN R156 SUMS + ISO/SAE 21434 + Automotive SPICE 4.0 + MISRA C:2023 + ISO 26262-6:2018 + AUTOSAR Classic R23-11 + ISO/IEC/IEEE 12207:2017 + ISO/IEC/IEEE 29148:2018 + ISO/IEC 25010:2023 + CISA SBOM Minimum Elements + CWE/CVE + CVSS v4.0
In the engineering-guide series we have described the lithium-ion battery with BMS and a thermal-runaway intro, the brake system, the motor and the controller, the suspension, the tyre, lighting and visibility, frame and fork, display + HMI, the SMPS CC/CV charger, connector + wiring harness, IP protection, bearings under ISO 281 L10, the stem and folding mechanism, the deck, handgrip + lever + throttle, the wheel as an assembly, fastener engineering as the joining axis, thermal management as the heat-dissipation axis, EMC/EMI as the interference-mitigation axis, cybersecurity as the interconnect-trust axis, NVH as the acoustic-vibration-emission axis, functional safety as the safety-integrity axis, battery lifecycle as the sustainability axis, repairability as the repairability axis, environmental robustness as the environmental-conditioning axis, privacy and personal-data protection as the privacy-preservation axis and reliability engineering as the reliability-prediction meta-axis. Those 28 engineering axes described subsystems, joining methods, thermal and electromagnetic phenomena, safety, sustainability, repairability, environmental conditioning, privacy and reliability engineering — yet all of them described software only obliquely: ED (functional safety) referenced ISO 26262 ASIL decomposition for SW; DZ (cybersecurity) referenced ISO/SAE 21434 TARA; ED and DZ together referenced UN R155/R156 — but none described the SW-process axis itself: how the firmware of embedded ECUs (motor controller + BMS + dashboard + IoT gateway + charger MCU) is developed, validated, versioned, traced, updated and monitored for vulnerabilities across the lifecycle.
Software & firmware engineering is the process axis of the entire e-scooter. It supplies process standards (Automotive SPICE 4.0 + ISO/IEC/IEEE 12207:2017 + IEC 62304 + DO-178C reference), technical coding standards (MISRA C:2023 + AUTOSAR C++14 Coding Guidelines), architectural frameworks (AUTOSAR Classic Platform R23-11 + AUTOSAR Adaptive Platform R23-11), safety overlays (ISO 26262-6:2018 SW level + Annex D Freedom from Interference), security overlays (ISO/SAE 21434:2021 + UN R155 CSMS + UN R156 SUMS), tool-qualification rules (ISO 26262-8 Clause 11 + DO-330), distribution formats (CISA SBOM Minimum Elements + SPDX 2.3 + CycloneDX 1.6 + Uptane OTA framework) and monitoring protocols (CWE Top 25 + CVE + CVSS v4.0 + VEX + CSAF). Without it there is no reproducible and traceable way to prove that the firmware currently running on your e-scooter’s ECU is the exact source code that passed TARA, ISO 26262 review and HALT.
This is the twenty-ninth engineering-axis deep-dive in the guide series — and the twelfth cross-cutting infrastructure axis (parallel to joining DT + heat-dissipation DV + interference-mitigation DX + interconnect-trust DZ + acoustic-vibration-emission EB + safety-integrity ED + sustainability EF + repairability EH + environmental-conditioning EJ + privacy-preservation EL + reliability-prediction EN, now SW-process EP). Like the reliability axis, the SW axis has no hardware “node” of its own — it is a process layer that overlays each of the 28 previous axes (firmware in the BMS, motor controller, dashboard, IoT gateway, charger).
1. SW axis ≠ cybersecurity ≠ functional safety ≠ reliability
SW engineering, cybersecurity, functional safety and reliability are often conflated — especially in marketing — but they solve different problems and are governed by different standards:
| Dimension | SW engineering (EP) | Cybersecurity (DZ) | Functional safety (ED) | Reliability (EN) |
|---|---|---|---|---|
| Question | How is software developed, tested, updated, traced? | What protects software from intentional attack? | What happens upon a random software fault? | How many hours until the software fails? |
| Artefact | SRS + SWE-AD + SWE-DD + tests + SBOM + traceability | TARA + CSMS + threat model + security goals | Safety case + ASIL allocation + FMEDA SW | Software reliability growth model + MTTF SW |
| Foundational standard | ISO/IEC/IEEE 12207:2017 + Automotive SPICE 4.0 + MISRA C:2023 | ISO/SAE 21434:2021 + UN R155 + UN R156 SUMS | ISO 26262-6:2018 Part 6 (Software) | ISO/IEC 25023:2016 SW reliability + Musa-Okumoto + Goel-Okumoto |
| Analytical tool | V-model + traceability matrix + static analysis + MC/DC | TARA + attack tree + EVITA model | Hazard analysis (HARA) + ASIL decomposition for SW + Annex D FFI | Software reliability growth modelling (Jelinski-Moranda, Littlewood-Verrall) |
| Engineering goal | Produce correct software predictably | Keep attackers out | Prevent cascading failure on a random fault | Predict how many defects appear over time |
| Validation cycle | A-SPICE assessment + audit + SQM | CSMS audit + pen-test | Safety audit + FMEDA + tool qualification | Field MTTF measurement + bug rate trend |
| Trigger | “How do we build it?” | “Who is attacking?” | “What might break?” | “When will it break?” |
A canonical example of the distinction: BMS firmware developed to ISO 26262-6:2018 Part 6 ASIL D (functional-safety axis) and ISO/SAE 21434:2021 CAL 4 (cybersecurity axis). Functional safety ensures: on a single-bit memory corruption, the MPU exception fires, the MCU transitions to the failsafe state (contactors open via relay). Cybersecurity ensures: no flashed firmware without a valid RSA-PSS signature ever boots (anti-tamper). Reliability predicts: a skewed Weibull (β = 0.8 in year one — software infant mortality caused by edge-case race conditions). SW engineering is a separate axis because it ensures: (a) the very source code that passed TARA and HARA actually ends up in the production binary, via a reproducible build; (b) every requirement in the SRS has a test case with a signed result; (c) a CVE-2026-NNNNN discovered in a dependency (e.g. mbedTLS) triggers a documented patch pipeline with an audit trail.
Without the SW axis, ISO 26262 and ISO/SAE 21434 and reliability are paper, not reality on the ECU.
2. Where firmware lives: five ECUs on an e-scooter
A modern e-scooter contains up to five separate ECUs with firmware, each with its own toolchain and its own update channel:
| ECU | Typical MCU/SoC | Firmware size | RTOS / bare-metal | Update channel | ASIL / CAL |
|---|---|---|---|---|---|
| Motor controller | STM32F4/F7 ARM Cortex-M4/M7, GD32F4, Renesas RH850 | 256 KB – 2 MB | FreeRTOS / Zephyr / bare-metal SVPWM loop | USB-CDC or CAN-bootloader via the service port | ASIL B (PMSM control loop) / CAL 2 |
| BMS controller | TI BQ76952, ADI ADBMS6815/6817, NXP MC33775, STM32L4 | 128 KB – 1 MB | Bare-metal or FreeRTOS | I²C/SPI with the motor controller (slave); OTA via the MCU host | ASIL D (thermal-runaway prevention) / CAL 3 |
| Dashboard / HMI | STM32H7 + LVGL, NXP iMX RT, Espressif ESP32-S3 | 1 – 8 MB (with LVGL + fonts) | FreeRTOS / Zephyr / Apache NuttX | Bluetooth LE OTA from the companion app | QM (no safety function) / CAL 1 |
| IoT gateway / telematics | Quectel BG95/EG95 (LTE-M/NB-IoT) + ESP32-S3, Nordic nRF9160 | 2 – 16 MB | Zephyr / FreeRTOS / Linux (Buildroot/Yocto for high-end) | Cellular OTA via MQTT broker or HTTPS | QM (cloud connectivity) / CAL 3-4 (gateway = attack surface) |
| Charger MCU | STM32G4 (digital SMPS), Microchip dsPIC33CK, TI C2000 F28004x | 64 – 512 KB | Bare-metal (100 kHz digital control loop) | USB-CDC service port; rarely OTA | ASIL A-B (IEC 62368-1 SELV/LPS) / CAL 1 |
Key observation: these five firmwares are not a single monolithic program. They are five separate processors with five separate toolchains (GCC ARM Embedded, IAR EWARM, Keil MDK, Renesas CS+, Microchip XC16), five separate build pipelines, five separate SBOMs, five separate OTA channels and frequently five separate suppliers (motor controller from Bosch, BMS from a TI reference design + a custom layer, dashboard from the OEM, IoT gateway from Quectel + a custom application, charger from Mean Well or CUI).
That means SW engineering for an e-scooter is multi-ECU systems engineering, not single-application development. The question “what firmware version is your scooter on?” is ill-formed — the right question is “Motor=v2.3.7, BMS=v1.8.1, Dashboard=v4.2.0, IoT=v5.1.3, Charger=v1.0.5” (five versions plus their interoperability matrix).
3. ISO/IEC/IEEE 12207:2017 — 30 processes in 4 groups
ISO/IEC/IEEE 12207:2017 (the third revision since 1995, harmonised with ISO/IEC/IEEE 15288 for systems engineering) is the reference standard for the software lifecycle. It does not prescribe a methodology (V-model vs Agile vs DevOps); instead it defines a vocabulary of 30 processes in 4 groups, from which any specific standard (A-SPICE, ISO 26262-6, IEC 62304, DO-178C) takes a subset and adds requirements.
| Group | Process count | Examples | What happens |
|---|---|---|---|
| Agreement processes | 2 | Acquisition + Supply | The e-scooter OEM buys a firmware stack from Tier-1 suppliers (Bosch motor controller + Texas Instruments BMS reference + Quectel IoT). The contract defines deliverables: source code? binary? SBOM? safety case? |
| Organizational Project-Enabling processes | 6 | Life Cycle Model Management + Infrastructure Management + Portfolio Management + Human Resource Management + Quality Management + Knowledge Management | The organisation builds a CI/CD infrastructure, maintains certified toolchains, manages knowledge (lessons learned, design-rationale archive) |
| Technical Management processes | 8 | Project Planning + Project Assessment and Control + Decision Management + Risk Management + Configuration Management + Information Management + Measurement + Quality Assurance | Project plan, deviation control, config management (Git + branch policy), progress measurement (burn-down, technical-debt index) |
| Technical processes | 14 | Business or Mission Analysis + Stakeholder Needs and Requirements Definition + System/Software Requirements Definition + Architecture Definition + Design Definition + System/Software Analysis + Implementation + Integration + Verification + Transition + Validation + Operation + Maintenance + Disposal | The engineering core itself: requirements → architecture → implementation → integration → V&V → deployment → maintenance |
The e-scooter firmware stack passes through all 30 processes for a production release: from Agreement (Bosch supplies its firmware to the OEM under NDA + escrow) to Disposal (how to wipe user data at scrapping — see the privacy axis and the recycling axis).
4. Automotive SPICE 4.0 — a V-model with 6 SWE + 5 SYS + 4 HWE + 4 MLE
Automotive SPICE 4.0 (Process Assessment Model, December 2023, published by VDA QMC) is the automotive-specific profile specialisation of ISO/IEC 33001 (Process Assessment) and ISO/IEC 33020 (Process Measurement Framework), with domain-specific process-capability ratings on levels 0–5 (Incomplete → Performed → Managed → Established → Predictable → Innovating). OEMs (BMW, Mercedes, Volkswagen, Stellantis) mandate that Tier-1 suppliers (Bosch, Continental, ZF, Aptiv) reach Capability Level 2 (Managed) for every VDA Scope process before SOP (Start of Production).
VDA Scope in A-SPICE 4.0 is split into a Basic Part + Domain Specific Parts (plug-ins). The Basic Part is mandatory; at least one plug-in must be selected:
| Part | Process Group | Processes | Assessed |
|---|---|---|---|
| Basic | MAN.3 + SUP.1 + SUP.8–10 | MAN.3 Project Management + SUP.1 Quality Assurance + SUP.8 Configuration Management + SUP.9 Problem Resolution + SUP.10 Change Request Management | Project plan + QA independence + Git-based config control + Jira-like issue tracking + change-request gate |
| SYS plug-in | SYS.1 → SYS.5 | SYS.1 Requirements Elicitation + SYS.2 System Requirements Analysis + SYS.3 System Architectural Design + SYS.4 System Integration and Integration Verification + SYS.5 System Qualification Testing | StRS → SyRS → SyAD → integration test → qualification test (the full system V-model) |
| SWE plug-in | SWE.1 → SWE.6 | SWE.1 Software Requirements Analysis + SWE.2 Software Architectural Design + SWE.3 Software Detailed Design and Unit Construction + SWE.4 Software Unit Verification + SWE.5 Software Component Verification and Integration + SWE.6 Software Verification | SRS → SwAD → SwDD + unit code + unit test + component test + SW qualification (the full software V-model) |
| HWE plug-in (NEW in 4.0) | HWE.1 → HWE.4 | HWE.1 Hardware Requirements Analysis + HWE.2 Hardware Design + HWE.3 Hardware Verification against Requirements + HWE.4 Hardware Verification | HRS → HwAD → schematics/PCB → HW prototype + EMC + reliability test |
| MLE plug-in (NEW in 4.0) | MLE.1 → MLE.4 | MLE.1 ML Requirements Analysis + MLE.2 ML Architecture + MLE.3 ML Training + MLE.4 ML Model Evaluation | ML datasets + training pipeline + model evaluation (relevant for e-scooter camera-based ADAS, lane-keeping vision, fall-detection ML) |
For an e-scooter, a Tier-1 OEM typically requires CL2 on the Basic + SYS + SWE plug-ins, sometimes CL2 on the HWE plug-in. The MLE plug-in is activated only if the scooter contains an ML model (e.g. pedestrian detection in premium models with a front camera, still rare for e-scooters but standard in L3–L7 mobility).
The A-SPICE 4.0 V-model for the SWE domain looks like this (left-to-right descent, then ascent up the right side of the V):
SYS.2 SyRS ────────────────────────────────────── SYS.5 System Qualification Test
│ ▲
▼ │
SWE.1 SRS ────────────────────────────── SWE.6 Software Qualification Test
│ ▲
▼ │
SWE.2 SwAD ──────────────────── SWE.5 SW Integration / Component Verification
│ ▲
▼ │
SWE.3 SwDD + Unit Construction ──── SWE.4 SW Unit Verification
│ ▲
└────── Implementation ──────────┘
Each horizontal line is traceability: a requirement in SyRS is linked (Polarion, IBM DOORS, Jama, ReqIF export) to a test case in SYS.5; a requirement in SRS — to a test case in SWE.6. Without a traceability matrix, the A-SPICE assessment does not pass.
5. ISO 26262-6:2018 — software level + Freedom from Interference
ISO 26262-6:2018 (Part 6: Product Development at the Software Level) is the safety overlay on the A-SPICE SWE processes. It adds 8 additional clauses (5–12) to the basic SW V-model:
| Clause | Topic | Requirement |
|---|---|---|
| 5 | General Topics | General requirements for SW dev |
| 6 | Initiation of Product Development at the Software Level | SW development plan + methods + tools |
| 7 | Specification of Software Safety Requirements | SwSR derived from SyRS + ASIL inheritance |
| 8 | Software Architectural Design | SwAD with partitioning + FFI demonstration |
| 9 | Software Unit Design and Implementation | Coding guidelines (MISRA C/C++) + defensive programming |
| 10 | Software Unit Verification | Unit test + static analysis + code review |
| 11 | Software Integration and Verification | SW-SW integration test + interface coverage |
| 12 | Verification of Software Safety Requirements | Functional, performance, robustness, interface tests |
The core — Clause 7.4.10 (Freedom from Interference, FFI): “If the embedded software has to implement software components of different ASILs, or safety-related and non-safety-related software components, then all of the embedded software shall be treated in accordance with the highest ASIL, unless freedom from interference between the software components is demonstrated.”
In plain English: if a BMS firmware contains both an ASIL D thermal-runaway monitor and a QM Bluetooth pairing UI, then either all of it must be developed to ASIL D (prohibitively expensive — MISRA mandatory rules + 100% MC/DC + double-precision arithmetic + redundancy everywhere) or FFI must be demonstrated so the QM part can remain QM.
Annex D identifies three categories of interference that must be blocked:
| FFI category | What is blocked | Technical mechanism |
|---|---|---|
| Spatial interference | The QM part cannot corrupt memory (data/code) of the ASIL D part | MPU (Memory Protection Unit) on ARM Cortex-M, MMU on ARM Cortex-A, OS partitions (FreeRTOS-MPU, SAFERTOS, QNX, INTEGRITY-178B); read-only code section, separate stacks |
| Temporal interference | The QM part cannot starve CPU time, preventing the ASIL D task from completing up to its deadline | Static cyclic scheduler (OSEK/AUTOSAR Classic), WCET (Worst Case Execution Time) analysis, watchdog timer, partition scheduler (ARINC 653-style) |
| Communication interference | The QM part cannot corrupt data consumed by the ASIL D part | E2E (End-to-End) protection per AUTOSAR (CRC + counter + ID), data-integrity checks, message authentication code (HMAC or CMAC) |
If FFI is demonstrated through MPU + static scheduler + E2E protection, the QM Bluetooth UI may stay QM and the ASIL D thermal-runaway monitor may stay ASIL D, and the two parts coexist in a single firmware binary. If FFI is not demonstrated, all of the firmware must be ASIL D — which for a typical 1 MB BMS firmware means a 2× to 5× cost increase (MISRA mandatory + 100% MC/DC + every line reviewed by an independent verifier).
6. MISRA C:2023 — directives + rules + decidability + advisory/required/mandatory
MISRA C (Motor Industry Software Reliability Association C Guidelines) is a coding standard dating to 1998, originally a UK automotive-industry consortium project, now a de facto mandatory standard for all ISO 26262 safety-critical SW and for many aerospace + medical contexts.
The current edition is MISRA C:2023, published in March 2023, which consolidates:
- MISRA C:2012 (base edition, 159 guidelines)
- Amendment 1: Additional rules for handling MISRA C:2012
- Amendment 2: Updates for ISO/IEC 9899:2011/2018 (C11/C18 language features)
- Amendment 3: Updates for ISO/IEC 9899:2011/2018 (continued)
- Amendment 4: Updates for ISO/IEC 9899:2011/2018 (full C11/C18 + atomics + threads support)
- Technical Corrigendum 1 + Technical Corrigendum 2
MISRA C:2023 has two categories of guidelines with different statuses:
| Category | Approximate count | How it is checked | Example |
|---|---|---|---|
| Directives | 17 | Manual review, because no algorithm can prove compliance from source code alone | “Dir 1.1: Any implementation-defined behaviour on which the output of the program depends shall be documented and understood” — requires reading the compiler documentation |
| Rules | 175+ | Static-analysis tool can check automatically (Coverity, Polyspace, LDRA, Helix QAC, PC-lint Plus) | “Rule 21.18: The size_t argument passed to any function in <string.h> shall have an appropriate value” — the tool analyses every call site |
Each rule is additionally classified as Decidable or Undecidable:
| Type | Meaning | Example |
|---|---|---|
| Decidable | An algorithm exists that returns yes/no for every source code | “Rule 14.1: A loop counter shall not have essentially floating type” — a straightforward syntactic check |
| Undecidable | Halting-problem-level — no algorithm can guarantee correct yes/no for all programs | “Rule 18.1: A pointer resulting from arithmetic on a pointer operand shall address an element of the same array as that pointer operand” — requires full alias analysis, NP-hard in general |
For undecidable rules, a static-analysis tool produces best-effort results with false positives / false negatives; MISRA Compliance:2020 (a separate document) defines how an OEM / Tier-1 declares compliance with undecidable rules via a deviation procedure (a documented exception with a technical rationale).
Beyond decidability, each guideline has an enforcement category:
| Category | Meaning | How the OEM treats it |
|---|---|---|
| Mandatory | Compliance is required, deviations are not allowed | Every violation is a blocker bug |
| Required | Compliance is required, but deviations are allowed with documentation + justification | The Tier-1 files a deviation form; the OEM safety team reviews |
| Advisory | Compliance is recommended, deviations do not require documentation | Can be ignored, but if enabled in the tool config, it is worth following |
For a typical BMS firmware of around 100 kLOC of C, companies expect 0 mandatory violations + ≤50 required deviations + N advisory violations before release. This reflects standard automotive practice: 100% mandatory compliance, documented deviations for required, advisory as guideline.
7. AUTOSAR Classic Platform R23-11 vs Adaptive Platform R23-11
AUTOSAR (AUTomotive Open System ARchitecture) is a partnership consortium of OEMs + Tier-1 (BMW, Bosch, Continental, Mercedes-Benz, PSA, Toyota, Volkswagen and others) standardising the software architecture for automotive ECUs since 2003. Modern releases ship twice a year under the formula Rxx-yy (year-month). As of May 2026 the current ones are AUTOSAR CP R23-11 (Classic Platform) and AUTOSAR AP R23-11 (Adaptive Platform).
| Aspect | AUTOSAR Classic Platform (CP) | AUTOSAR Adaptive Platform (AP) |
|---|---|---|
| ECU type | Deeply embedded MCU (ARM Cortex-M, Renesas RH850, PowerPC e200, Aurix TriCore) | High-performance computing ECU (ARM Cortex-A, x86_64) |
| Memory budget | KB–MB Flash, KB RAM | GB Flash, GB RAM |
| Architecture | 3-layer: Application → RTE → Basic Software (BSW) → MCAL → MCU | Service-Oriented Architecture (SOA) with ARA (AUTOSAR Runtime for Adaptive Applications) on a POSIX OS |
| Configuration | Static, build-time (ARXML → code generation → linked binary) | Dynamic, runtime service discovery |
| Communication | CAN/CAN FD/LIN/FlexRay/Ethernet via the COM stack | SOME/IP Service Discovery + DDS + ROS2 |
| OS | OSEK/VDX (now AUTOSAR OS) with a fixed-priority preemptive scheduler | POSIX-compatible (PSE51 profile) — Linux, QNX, INTEGRITY-178B |
| E-scooter relevance | Motor controller, BMS, charger MCU, simpler dashboards | IoT gateway, premium dashboards with navigation/AR, future autonomy stack |
| ASIL/CAL coverage | Up to ASIL D | Up to ASIL B today (storage/POSIX limitations), evolving |
Classic Platform 3-layer architecture:
┌─────────────────────────────────────────────────────┐
│ Application Layer (SWCs — Software Components) │
│ (Motor control SWC, BMS SWC, Diag SWC, etc.) │
├─────────────────────────────────────────────────────┤
│ RTE (Runtime Environment) │
│ — code-generated glue between SWCs and BSW │
├─────────────────────────────────────────────────────┤
│ Basic Software (BSW) │
│ ├─ Services Layer (Diag, Memory, Comm, System) │
│ ├─ ECU Abstraction Layer (PortIf, Eep, Fls, Spi) │
│ └─ Microcontroller Abstraction Layer (MCAL) │
│ (CAN driver, ADC driver, PWM driver, etc.) │
├─────────────────────────────────────────────────────┤
│ Microcontroller (STM32F4, RH850, Aurix TC3xx) │
└─────────────────────────────────────────────────────┘
ARXML (AUTOSAR XML) is the formal model of the whole stack: SWCs, runnables, RTE events, BSW configuration. Tools (Vector DaVinci Developer, EB tresos, Mentor Volcano) generate the RTE code and BSW config from ARXML.
For an e-scooter, the Classic Platform is overkill for most builds (licence cost from US$50–200k per project), but OEM-to-Tier-1 contracts frequently require AUTOSAR Classic for the motor controller + BMS, otherwise the firmware does not slot into the Tier-1 production toolchain.
8. ISO/SAE 21434:2021 + UN R155 CSMS — TARA in the SW context
ISO/SAE 21434:2021 (Road vehicles — Cybersecurity engineering, August 2021) is a joint publication of ISO TC22/SC32 and SAE Vehicle Cybersecurity Systems Engineering. Unlike ISO 26262 (random/systematic faults), ISO/SAE 21434 addresses intentional attacks.
The standard is organised into 15 clauses, with the key ones:
| Clause | Topic |
|---|---|
| 5 | Overall cybersecurity management |
| 6 | Project-dependent cybersecurity management |
| 7 | Distributed cybersecurity activities (between OEM and Tier-1) |
| 8 | Continual cybersecurity activities (post-production monitoring) |
| 9 | Concept (item definition + TARA + cybersecurity goals + cybersecurity concept) |
| 10 | Product development |
| 11 | Cybersecurity validation |
| 12 | Production |
| 13 | Operations and maintenance (vulnerability monitoring + incident response) |
| 14 | End of cybersecurity support and decommissioning |
| 15 | TARA methodology |
TARA (Threat Analysis and Risk Assessment) is the core methodology of Clause 15:
Item definition + Asset identification
│
▼
Threat-scenario identification (per asset)
│
▼
Impact rating (Safety + Financial + Operational + Privacy: S/F/O/P)
│
▼
Attack-path analysis (attack tree)
│
▼
Attack-feasibility rating (Elapsed Time + Expertise + Knowledge + Opportunity + Equipment)
│
▼
Risk determination (Impact × Feasibility) → CAL (Cybersecurity Assurance Level)
│
▼
Risk treatment (Avoid / Reduce / Share / Retain)
Risk treatment produces Cybersecurity Goals (high-level security properties), which are then progressively decomposed into Cybersecurity Claims and Cybersecurity Controls (concrete technical mechanisms). CAL 1–4 (lowest to highest) defines the recommended degree of rigour, analogously to ASIL in functional safety.
An important note on scope: ISO/SAE 21434 formally excludes two-wheelers in its scope text, because L-category transport is regulated separately by UNECE WP.29 GRBP. However, for an e-scooter classed as L1e-A / L1e-B / L3e (under the EU 168/2013 framework regulation), UN R155 (Cyber Security and CSMS) is mandatory from December 2027 for new types and June 2029 for existing types. ISO/SAE 21434 is the methodological baseline for fulfilling UN R155 requirements. In practice, e-scooter OEMs use the ISO/SAE 21434 TARA workflow as the technical implementation of CSMS claims.
A detailed treatment of threat modelling, attack surfaces, the EVITA model and pen-testing is in the interconnect-trust axis (cybersecurity). Here we focus on the SW-engineering integration of TARA: every Cybersecurity Claim from Clause 9 must have a traceability link to the concrete code, test and SBOM component that implements it.
9. UN R156 SUMS — Software Update Management System
UN R156 (UNECE Regulation No. 156 — Software Update and Software Update Management System) is a WP.29 (World Forum for Harmonization of Vehicle Regulations) regulatory requirement that obliges the OEM to maintain a documented process for:
- Issuing software updates (including a definition of what counts as a software update vs a calibration update vs a content update)
- Tracking which vehicles run which software version
- Verifying compatibility before an update (e.g. BMS firmware v1.8.1 requires motor controller firmware ≥ v2.3.5, not v2.2)
- Demonstrating impact of the update on (a) type-approval relevance — does it constitute a new vehicle type? (b) safety — does it affect UN R157 ALKS, UN R79 steering? (c) cybersecurity — does it close a CVE? (d) emissions — does it affect Euro X compliance?
- Authentication, integrity, rollback protection for the update process itself
- Driver / user notification when needed (e.g. on the dashboard UI: “Update available, restart required, charged ≥ 50%”)
- Record-keeping of every ECU + every version + every update event throughout the vehicle’s life (a minimum of 10 years after SOP)
| Vehicle Category | UN R155/R156 new types from | UN R155/R156 existing types from |
|---|---|---|
| M, N (passenger cars + trucks) | July 2022 | July 2024 |
| O (trailers + semi-trailers, electronic systems only) | July 2022 | July 2024 |
| L (motorcycles, e-scooters, e-bikes — L1e, L3e, L6e, L7e) | December 2027 | June 2029 |
For an e-scooter ranging from L1e-A (slow electric bicycle, ≤ 25 km/h) to L3e (high-power e-scooter, > 35 km/h, > 11 kW), UN R156 SUMS will be mandatory from December 2027 for new type approvals.
SUMS structure (in practice):
| SUMS component | Technical implementation |
|---|---|
| Software identification | Unique software ID per ECU (e.g. BMS-v1.8.1-build42-sha256:abcd…); stored in ECU NVM + reported via service tool |
| Vehicle interdependency database | OEM cloud DB that maps VIN → a set of (ECU, version) tuples |
| Compatibility matrix | Before allowing an update: cross-check that the new combination (ECU1=v1.8.2, ECU2=v2.3.7, …) has been officially validated |
| Update authentication | Signed binary (RSA-PSS-2048 / RSA-PSS-3072 / ECDSA-P-256) with a trust chain anchored at the OEM root CA |
| Integrity check | SHA-256 hash of the binary, signed within the manifest |
| Rollback protection | Monotonic counter incremented per release, stored in a tamper-resistant location (HSM, SHE module, OTP fuse). Older firmware = lower counter = refuse boot |
| Pre-conditions | Battery charge level, parking state, gear position, network-connectivity check |
| User consent (M-category) / silent install (L-category permitted) | Impact-dependent — a safety-critical update may be forced; non-safety — opt-in |
| Audit trail | Every update attempt (success / fail / aborted) is logged with VIN + ECU + from-version + to-version + timestamp + outcome |
| Post-update verification | Smoke test: does the ECU boot? does the self-test pass? is communication with the other ECUs healthy? if not — roll back to the previous version |
De facto implementation for L-category e-scooters: the Uptane framework (described in § 15) satisfies most cryptographic vehicle-side requirements, while on the cloud side the OEM deploys TUF (The Update Framework) repositories with Director and Image roles. Open-source implementations: Eclipse Hawkbit (Bosch IoT Suite), Mender.io, Foundries.io LmP.
10. SBOM — Software Bill of Materials per CISA Minimum Elements
SBOM (Software Bill of Materials) is a machine-readable list of every software component in a firmware: imports, libraries, dependencies, transitive dependencies down to the nth degree. For an embedded ECU this can be 200–500 records (a typical FreeRTOS-based BMS firmware contains a FreeRTOS kernel + mbedTLS + lwIP + STM32 HAL + STM32 LL + custom application code + several smaller helper libraries).
The SBOM answers the question: “Does this firmware contain version X of library Y, in which CVE-Z is open?” — without having to reverse-engineer the binary.
Regulatory basis: U.S. Executive Order 14028 (May 2021, “Improving the Nation’s Cybersecurity”) requires SBOMs for federal software. NTIA published “The Minimum Elements For a Software Bill of Materials (SBOM)” in July 2021, defining seven baseline data fields. CISA (Cybersecurity and Infrastructure Security Agency) took over the standard in 2023, and in 2025 published a draft update with three additional fields:
| Field (NTIA 2021) | Description |
|---|---|
| Supplier Name | Component supplier (e.g. “STMicroelectronics” for the STM32 HAL) |
| Component Name | Name of the component (“STM32CubeF4 HAL Driver”) |
| Version of the Component | SemVer or vendor-specific (“v1.27.4”, or a git commit hash) |
| Other Unique Identifiers | PURL (Package URL), CPE (Common Platform Enumeration), SWID tag, or an internal SKU |
| Dependency Relationship | Which component depends on which |
| Author of SBOM Data | Who generated this SBOM (OEM Tier-1, vendor self-attestation, third party) |
| Timestamp | When the SBOM was generated (important for vulnerability matching) |
| Field (CISA 2025 draft, additional) | Description |
|---|---|
| Component Hash | Cryptographic hash (SHA-256 minimum) for binary identification |
| License | SPDX-License-Identifier (e.g. MIT, Apache-2.0, GPL-3.0-or-later) for legal compliance |
| Tool Name | SBOM-generation tool (Syft, Trivy, ScanCode, custom) for reproducibility |
| Generation Context | Build-time / source / binary / deployment (where in the lifecycle the SBOM was generated) |
Formats:
| Format | Origin | Strength |
|---|---|---|
| SPDX 2.3 / 3.0 | Linux Foundation, ISO/IEC 5962:2021 | License-centric, mature, ISO-standardised |
| CycloneDX 1.6 | OWASP | Security-centric, native VEX support, BOM-Link |
| SWID Tags | ISO/IEC 19770-2:2015 | Asset-management origin; CISA 2025 deprecates |
For an embedded ECU firmware the best practice is CycloneDX 1.6 JSON with fully enumerated dependencies, attached at firmware release as .cdx.json in the same directory as the .bin. The OEM cloud stores an SBOM per ECU per version and matches it against the live CVE feed (NVD) for proactive vulnerability disclosure.
11. Vulnerability tracking — CWE + CVE + CVSS v4.0 + VEX + CSAF
Knowing “the firmware contains mbedTLS v3.4.1 as a component” is the SBOM. Knowing “mbedTLS v3.4.1 has CVE-2024-23170, an ECDSA timing side-channel with CVSS 5.9” is vulnerability management. Four standard artefacts:
| Artefact | Origin | What it describes |
|---|---|---|
| CWE (Common Weakness Enumeration) | MITRE, NIST SP 800-126 | Classes of weaknesses (CWE-79 XSS, CWE-89 SQL injection, CWE-787 Out-of-bounds Write, CWE-416 Use After Free, CWE-20 Improper Input Validation). CWE Top 25 is an annually updated ranking of the most frequent CWEs in the CVE feed |
| CVE (Common Vulnerabilities and Exposures) | MITRE-managed, CNAs (CVE Numbering Authorities) | Concrete instances: CVE-YYYY-NNNNN, listing vendor + product + version + CWE clause + references |
| CVSS v4.0 (Common Vulnerability Scoring System) | FIRST.org, published 1 November 2023 | Severity score 0.0–10.0 (None/Low/Medium/High/Critical) based on 4 metric groups |
| VEX (Vulnerability Exploitability eXchange) / OpenVEX / CSAF | OASIS CSAF + OpenSSF OpenVEX | Status statement: “CVE-X in component Y is NOT_AFFECTED in our product (because reason)” or “AFFECTED + remediation pending until date Z” |
CVSS v4.0 is the current edition, superseding CVSS v3.1 (2019). Changes:
| Metric Group | CVSS v3.1 | CVSS v4.0 (new) |
|---|---|---|
| Base | AV/AC/PR/UI + S + CIA | AV/AC/AT (Attack Requirements, new) + PR/UI + VC/VI/VA (Vulnerable system Confidentiality/Integrity/Availability) + SC/SI/SA (Subsequent system) |
| Temporal → Threat | E/RL/RC | E (Exploit Maturity) only — simplified |
| Environmental | CR/IR/AR + Modified Base | MAV/MAC/MAT/MPR/MUI/MVC/MVI/MVA/MSC/MSI/MSA + CR/IR/AR |
| Supplemental (NEW in 4.0) | — | Safety + Automatable (wormable) + Recovery + Value Density + Vulnerability Response Effort + Provider Urgency |
The Safety supplemental metric in CVSS v4.0 is specifically for cyber-physical systems (including e-scooters): “Can exploitation of this vulnerability cause physical safety harm?” Valuable for an e-scooter: if a CVE in motor-controller firmware allows remote brake disable — Safety: Present, which lifts the priority above the pure information-security CVSS score.
Workflow:
SBOM published with firmware release
│
▼
Per component → query NVD CVE feed → match CPE/PURL → list of CVEs
│
▼
Per CVE → CVSS v4.0 Base + Threat + Environmental + Supplemental → priority
│
▼
VEX statement: AFFECTED / NOT_AFFECTED / FIXED / UNDER_INVESTIGATION
│
▼
If AFFECTED + Safety supplemental Present → emergency patch pipeline
If AFFECTED + Safety supplemental Negligible → next regular release
│
▼
Public CSAF advisory (OASIS Common Security Advisory Framework JSON)
12. Tool qualification per ISO 26262-8 Clause 11 — TCL + TI + TD
When developing safety-critical SW, a tool (compiler, static analyser, model-based tool, code generator) must itself be shown not to introduce errors into the resulting artefact. This is tool qualification, described in ISO 26262-8:2018 Clause 11.
Tool Confidence Level (TCL) is computed from two inputs:
| Input | Scale | Meaning |
|---|---|---|
| Tool Impact (TI) | TI1 / TI2 | TI1: a malfunction cannot cause a safety violation (e.g. an IDE formatter). TI2: it can (e.g. a compiler) |
| Tool Error Detection (TD) | TD1 / TD2 / TD3 | TD1: high likelihood of detecting the tool error downstream (compile + unit test). TD2: medium. TD3: low (a single point of failure) |
TCL determination matrix:
| TI \ TD | TD1 (high detection) | TD2 (medium) | TD3 (low) |
|---|---|---|---|
| TI1 (low impact) | TCL1 | TCL1 | TCL1 |
| TI2 (high impact) | TCL1 | TCL2 | TCL3 |
| TCL | Required action |
|---|---|
| TCL1 | The tool can be used without qualification (does not affect safety) |
| TCL2 | The tool must be qualified by one of 4 methods |
| TCL3 | The tool must be qualified by one of 4 methods (same options, but stricter rigour) |
Four qualification methods (Clause 11.4.6):
| Method | Description | Example |
|---|---|---|
| 1a | Increased confidence from use | The tool has been used industry-wide for ≥ 1 year without incident |
| 1b | Evaluation of the tool development process | The tool itself was developed under ISO 26262 (recursive) |
| 1c | Validation of the tool | The OEM validates each tool release with a test suite that covers their usage |
| 1d | Development in accordance with a safety standard | The vendor developed the tool to ISO 26262 from scratch |
Practice: for ASIL D motor-controller firmware, typical qualified tools:
- Compiler: GCC ARM Embedded —
arm-none-eabi-gcc— TÜV SÜD certified release. Or IAR Systems EWARM with the SafetyDoc package. Or the Tasking VX-toolset. - Static analyser: LDRA Testbed, Coverity Polaris, Perforce Helix QAC, Polyspace Bug Finder — TÜV-certified for ISO 26262 use.
- Code coverage: VectorCAST, LDRA Testbed coverage, Squore.
- Model-based code generator: MathWorks Simulink Embedded Coder with the DO-178C / ISO 26262 Tool Qualification Kit.
Qualification artefacts (Tool Safety Manual, Tool Operating Conditions, Tool User Guide) are supplied by the vendor alongside the tool and enter the safety case of the firmware in question.
13. ISO/IEC/IEEE 29148:2018 + EARS — requirements engineering
ISO/IEC/IEEE 29148:2018 (Systems and software engineering — Life cycle processes — Requirements engineering) is the standard on how to write requirements. It covers the entire requirements lifecycle: elicitation → analysis → specification → verification → validation → management.
The standard defines a three-tier document hierarchy (matched to A-SPICE SYS.1 → SYS.2 → SWE.1):
| Document | Content | Author | Reader |
|---|---|---|---|
| StRS (Stakeholder Requirements Specification) | What users want (use cases, business needs, regulatory) | Marketing + Product Management + Compliance | Product team |
| SyRS (System Requirements Specification) | What the system does (functional + non-functional, hardware + software inclusive) | Systems engineer | SW + HW + MechE teams |
| SRS (Software Requirements Specification) | What the software does (per ECU) | Software architect | Software developers + Test engineers |
EARS (Easy Approach to Requirements Syntax) is a notation for writing requirements that reduces ambiguity. Five patterns:
| Pattern | Template | Example for BMS firmware |
|---|---|---|
| Ubiquitous | The <system> shall <response> | The BMS shall maintain cell voltage measurement accuracy of ±5 mV at 25 °C. |
| Event-driven | When <trigger>, the <system> shall <response> | When any cell voltage exceeds 4.25 V for 100 ms, the BMS shall open the charge MOSFET within 50 ms. |
| Unwanted behaviour | If <unwanted condition>, then the <system> shall <response> | If communication with the motor controller is lost for > 200 ms, then the BMS shall enter limp-home mode at 50% rated current. |
| State-driven | While <state>, the <system> shall <response> | While in over-temperature state (T_cell > 60 °C), the BMS shall reduce maximum discharge current to 10 A. |
| Optional feature | Where <feature included>, the <system> shall <response> | Where SoC estimation via coulomb counting is enabled, the BMS shall recalibrate at each full-charge event. |
An EARS-formulated requirement is easier to put through an automated requirement-quality checker (Visure, Polarion, IBM ELM) and traces back to a single test case without ambiguity.
14. ISO/IEC 25010:2023 — 8 characteristics of the product quality model
ISO/IEC 25010:2023 (Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality model) is a taxonomy of non-functional requirements. It replaces ISO/IEC 9126 (2001) and ISO/IEC 25010:2011.
| Characteristic | Sub-characteristics | E-scooter relevance |
|---|---|---|
| Functional Suitability | Completeness + Correctness + Appropriateness | Are all SyRS requirements implemented? Correctly? |
| Performance Efficiency | Time behaviour + Resource utilisation + Capacity | Motor-control loop ≥ 20 kHz, CPU < 70%, RAM < 80% |
| Compatibility | Coexistence + Interoperability | Neighbouring firmware on an ECU does not crash during a concurrent OTA |
| Interaction Capability (NEW in 2023, replaces Usability) | Appropriateness recognisability + Learnability + Operability + User-error protection + UX + Inclusivity + Accessibility | Dashboard UX, voice prompts, screen-reader support |
| Reliability | Maturity + Availability + Fault tolerance + Recoverability | Software MTBF, watchdog recovery, EEPROM-corruption handling |
| Security | Confidentiality + Integrity + Non-repudiation + Accountability + Authenticity + Resistance | Per ISO/SAE 21434 |
| Maintainability | Modularity + Reusability + Analysability + Modifiability + Testability | OTA partition layout, log granularity, on-target debugger access |
| Flexibility (NEW in 2023, replaces Portability) | Adaptability + Scalability + Installability + Replaceability | Cross-MCU portability via HAL, A/B partition support, OTA install resume |
| Safety (NEW in 2023) | Operational constraint + Risk identification + Fail safe + Hazard warning + Safe integration | Per ISO 26262 + UNECE GTR 22 |
An e-scooter SQM (Software Quality Management) team produces a Quality Plan that maps each sub-characteristic to a measurable metric and an acceptance criterion before release.
15. OTA bootloader: A/B partition + secure boot + rollback protection + Uptane
OTA updates are implemented on an ECU via a primary bootloader → secondary update bootloader → application chain with an A/B partition layout:
Flash memory layout (typical STM32F4, 1 MB Flash):
0x08000000 ┌─────────────────────────────┐ Primary Bootloader (16 KB)
│ ROM-protected, immutable │ Hardware Root of Trust, verifies
│ Secure-boot stage 1 │ signature of secondary bootloader
0x08004000 ├─────────────────────────────┤
│ Secondary Update Bootloader │ MCUboot or AUTOSAR FBL or proprietary
│ (64 KB) │ Validates signature of application
│ — header parsing │ Manages A/B swap
│ — signature verification │ Anti-rollback counter check
│ — OTA staging │
0x08014000 ├─────────────────────────────┤
│ Application Slot A (464 KB) │ Current firmware image
│ — header: version + hash │
│ — image binary │
│ — signature (ECDSA-P-256) │
0x08088000 ├─────────────────────────────┤
│ Application Slot B (464 KB) │ Next firmware image (or previous, post-swap)
│ — same layout as Slot A │
0x080FC000 ├─────────────────────────────┤
│ NVM / Config / Logs (16 KB) │ Persistent state
0x080FFFFF └─────────────────────────────┘
Update flow (Uptane-compliant):
- Download — the IoT gateway pulls a signed image manifest from the Director repository (per-vehicle, ephemeral) + an image from the Image repository (CDN, immutable). The manifest contains hash + signature + version + ECU target.
- Manifest verification — the secondary bootloader verifies the manifest signature using the Director public key (TUF Targets role).
- Image verification — the image hash matches the hash in the manifest; the image signature (ECDSA-P-256 over SHA-256) is verified with the vendor public key (TUF Targets role).
- Rollback check — is the image version counter > the current monotonic counter? If not — refuse. The counter is stored in HSM / SHE / OTP fuse, and cannot be reset by software alone.
- Staging — the image is written into the inactive partition (if we are currently booting from A, we write into B).
- Atomic swap — after the write completes + verification, the NVM precondition flag is set to “boot from B” (a single-write atomic flip).
- Reboot — the primary bootloader reads the flag, jumps to B.
- Post-boot validation — the secondary bootloader runs a self-test (peripheral init, communication check, internal consistency). If pass — confirm boot success (the rollback counter is advanced). If fail within N seconds — the primary bootloader detects a watchdog reset, flips the flag back to “boot from A”, recovery.
Secure-boot stack (Root of Trust → application chain):
HSM / SHE / OTP fuse
│ stored: vendor root CA public key (RSA-3072 or ECDSA-P-384)
▼
Primary bootloader (ROM, immutable)
│ verifies: signature of secondary bootloader against vendor root CA
▼
Secondary update bootloader
│ verifies: application signature against vendor signing key (intermediate CA)
│ checks: monotonic counter ≥ current
│ checks: image hash matches manifest
▼
Application firmware
│ runs: SVPWM loop, BMS protection, communication, diagnostics
Uptane (uptane.github.io) is an OTA framework designed specifically for road vehicles, evolved from TUF (The Update Framework). Its key extension over TUF is the Director repository (per-vehicle ephemeral manifests that bind versions to VIN + ECUs in a tamper-resistant way). Open-source implementations: aktualizr (HERE Technologies, now Foundries), Uptane Standalone Verification Library, Eclipse Hawkbit Update Server.
Alternatives (outside Uptane):
- MCUboot (Linaro Project) — a secure bootloader for embedded MCUs, with native A/B swap + image signing. Supports Arm Cortex-M, RISC-V, Xtensa. Open-source Apache-2.0.
- AUTOSAR Classic Flash Bootloader — proprietary, integrated with the AUTOSAR Diagnostic stack (UDS ISO 14229). Usually vendor-supplied (Vector, ETAS, EB).
- systemd-boot + dm-verity + casync — Linux-based, for high-end IoT gateways (e.g. Nvidia Jetson Nano for an AR navigation HUD).
16. Cross-axis matrix: SW concept × 28 existing engineering axes
SW engineering is a meta-axis, so every previous engineering axis has a SW aspect. The mapping of concept to axis:
| Engineering axis | SW relevance |
|---|---|
| DT Joining / fasteners | No firmware aspect — purely mechanical. SW-irrelevant. |
| DV Heat dissipation / thermal | Motor-controller derating algorithm in firmware: temperature → current-limit lookup table |
| DX Interference / EMC | Watchdog-refresh strategy on EMI-induced single-bit flip; CRC on every CAN frame |
| DZ Cybersecurity | TARA → cybersecurity claims → SRS items → SWE.3 implementation → SWE.6 test. Direct integration |
| EB NVH | Motor SVPWM tuning in firmware affects the acoustic emission spectrum (10 kHz SVPWM tone) |
| ED Functional safety | ASIL allocation → ISO 26262-6 SW process → SWE.3 with MISRA C — direct overlay |
| EF Sustainability / lifecycle | Coulomb-counter calibration in BMS firmware drives accuracy of SoH estimation for secondary use |
| EH Repairability | Service-tool API (UDS ISO 14229 on CAN, JTAG/SWD protected by password) — firmware exposes |
| EJ Environmental robustness | Temperature-compensation algorithm in firmware (sensor reading drift vs T) |
| EL Privacy | Telemetry minimisation in IoT-gateway firmware; consent management in dashboard UI |
| EN Reliability | Software reliability growth model (Musa-Okumoto, Goel-Okumoto); bug density per kLOC; field MTTF for SW |
| Battery + BMS | BMS firmware: cell-balancing algorithm, SoC/SoH estimation Kalman filter, contactor logic |
| Brake system | Brake-by-wire firmware (rare on e-scooters), ABS algorithm (where present) |
| Motor + controller | SVPWM, FOC (Field Oriented Control), torque-ripple compensation, PMSM commutation |
| Suspension | Semi-active suspension control (rare on e-scooters, but in CycleBoard premium models) |
| Tyre | TPMS firmware (where present): pressure sample rate, low-pressure alarm threshold |
| Lighting / visibility | LED PWM dimming, brake-light timing logic, indicator pattern generator |
| Frame / fork | No firmware — purely mechanical. |
| Display / HMI | LVGL / TouchGFX framework, UI state machine, font rendering, animation engine |
| Charger SMPS | CC/CV state machine in charger MCU firmware, handshake with BMS over the communication line |
| Connectors / wiring harness | Firmware side: line-fault detection, redundant signal coverage |
| IP protection | Firmware side: humidity-sensor monitoring (where present), condensation alarm |
| Bearings | No firmware — purely mechanical. |
| Stem / folding | Folding sensor (Hall + magnet) → firmware refuses motor enable when folded |
| Deck / footboard | Rider-detection sensor → motor cut-off logic |
| Handgrip + lever + throttle | Hall throttle ADC + filter + ramp-up curve in firmware; lever debounce algorithm |
| Wheel / rim / spoke | No firmware — purely mechanical. |
| Acceleration + throttle control | Throttle map (linear / progressive / sport), max-acceleration limiter |
| Regenerative braking | Regen-current ramp algorithm in motor-controller firmware |
11 of the 28 axes (joining, frame, bearings, wheel + 7 “hard” mechanical) have no firmware aspect — they are pure mechanics. 17 of the 28 have a direct firmware overlay. In practice the SW axis integrates most tightly with ED (functional safety), DZ (cybersecurity), Motor + controller, BMS, and Dashboard.
17. Seven-step DIY SW hygiene for the owner
An e-scooter owner has no firmware-development toolchain, but can maintain SW hygiene:
- Record every version. At purchase and after every service, ask the dealer: “What firmware versions are on the motor controller, BMS, dashboard, IoT gateway, charger today?” Note them in the service book. Without this, you cannot know whether recent CVEs are closed.
- Track recall + OTA notifications. OEMs publish safety / cybersecurity bulletins (UN R155 Clause 8 Continual cybersecurity activities). Subscribe to the manufacturer’s email channel.
- Do not block OTA. If the dashboard shows “Update available” — do not defer for long. Forced UN R156 updates for critical security CVEs become lawful in the L category from 2027.
- Verify the source before any manual flash. If you are a tuner and run custom firmware — make sure the source is a verified GitHub repository with GPG-signed commits. Do not flash a binary from an anonymous Telegram channel — that is a classic supply-chain attack vector.
- Keep recovery firmware. Before any custom modification, save the OEM image to an SD card. UN R156 SUMS would have manufacturers do this automatically, but not every small-brand OEM is compliant.
- Verify certificates. If a service tool (e.g. Ninebot Diag, KingSong service tool) asks for an admin password for a firmware update — do not provide it without verifying with the OEM. Many pseudo-service tools are malware dumping firmware for analysis.
- Document incidents. If firmware behaves strangely (random reboots, motor cut-off without cause, dashboard freezes) — record timestamp + circumstances + last known firmware version. That allows the dealer to correlate quickly with a known CVE or bug.
18. Recap: the SW axis in 10 points
- SW engineering is the process axis of every other axis. Without it, ISO 26262 + ISO/SAE 21434 + ALT/HALT are paper, not reality on the ECU.
- Five ECUs in a typical e-scooter: motor controller + BMS + dashboard + IoT gateway + charger. Five firmwares, five toolchains, five SBOMs, five update channels.
- ISO/IEC/IEEE 12207:2017 is the lifecycle skeleton — 30 processes in 4 groups. Automotive SPICE 4.0 is the automotive specialisation with SYS/SWE/HWE/MLE plug-ins. CL2 is the expected level before SOP.
- ISO 26262-6:2018 Clause 7.4.10 + Annex D — Freedom from Interference: spatial (MPU) + temporal (scheduler + WCET) + communication (E2E protection) are mandatory for mixed-ASIL firmware.
- MISRA C:2023 is the C coding standard: directives + rules, decidable + undecidable, mandatory + required + advisory. Zero mandatory violations expected.
- AUTOSAR Classic Platform R23-11 for deeply-embedded MCUs (motor controller, BMS, charger); Adaptive Platform R23-11 for high-performance ECUs (IoT gateway).
- ISO/SAE 21434:2021 + UN R155 — TARA → CSMS → Cybersecurity Claims traced down to SW. UN R156 SUMS becomes mandatory for L-category vehicles from December 2027 for new types.
- SBOM per CISA Minimum Elements 2025 — 11 fields (7 NTIA 2021 baseline + 4 new CISA: hash + license + tool + context). Format: SPDX 2.3 or CycloneDX 1.6.
- CVE + CVSS v4.0 — vulnerability tracking. The Safety supplemental metric is specifically for cyber-physical systems. VEX + CSAF are the status artefacts. The per-CVE patch SLA is defined in the CSMS.
- OTA + secure boot + A/B partition + rollback protection + Uptane framework — defence in depth for firmware integrity. HSM/SHE root of trust → secondary bootloader → application chain. A monotonic counter blocks anti-rollback attacks.
The SW axis makes all previous engineering axes reproducible: the very firmware that passed TARA + ISO 26262 review + ALT ends up — guaranteed — on the ECU after the production line, an OTA update, or a field repair. Without the SW axis, the engineering corpus remains theory on paper; with the SW axis, it becomes reality on the flash chip of the e-scooter you hold in your hands.
Sources
Process + lifecycle standards.
- ISO/IEC/IEEE 12207:2017 — Systems and software engineering — Software life cycle processes. International Organization for Standardization.
- Automotive SPICE Process Assessment Model v4.0 (December 2023). VDA Quality Management Center.
- ISO/IEC/IEEE 29148:2018 — Systems and software engineering — Life cycle processes — Requirements engineering.
- ISO/IEC 25010:2023 — Systems and software engineering — SQuaRE — Product quality model.
- IEC 62304:2006 + A1:2015 — Medical device software — Software life cycle processes.
- RTCA DO-178C / EUROCAE ED-12C — Software Considerations in Airborne Systems and Equipment Certification (2011). Reference for non-automotive comparison.
Safety standards.
- ISO 26262-6:2018 — Road vehicles — Functional safety — Part 6: Product development at the software level.
- ISO 26262-8:2018 — Road vehicles — Functional safety — Part 8: Supporting processes (Clause 11 Tool qualification).
Cybersecurity standards.
- ISO/SAE 21434:2021 — Road vehicles — Cybersecurity engineering.
- UNECE Regulation No. 155 — Cyber Security and Cyber Security Management System.
- UNECE Regulation No. 156 — Software Update and Software Update Management System.
- The Road Vehicles (Type-Approval) (Amendment No. 3) Regulations 2025 — Cyber Security and Software Updates (UK implementation).
Coding standards.
- MISRA C:2023 — Guidelines for the use of the C language in critical systems. MISRA Consortium.
- MISRA C:2012 Amendment 4 — Updates for ISO/IEC 9899:2011/2018.
- MISRA Compliance:2020 — Achieving compliance with MISRA Coding Guidelines.
- AUTOSAR C++14 Coding Guidelines (release R22-11).
Architectural frameworks.
- AUTOSAR Classic Platform Release R23-11. AUTOSAR Partnership.
- AUTOSAR Adaptive Platform Release R23-11.
SBOM + supply chain.
- The Minimum Elements For a Software Bill of Materials (SBOM). NTIA, July 2021.
- CISA Minimum Elements for SBOM (2025 Draft). U.S. Cybersecurity and Infrastructure Security Agency.
- SPDX 2.3 Specification. Linux Foundation / ISO/IEC 5962:2021.
- CycloneDX 1.6 Specification. OWASP Foundation.
- ISO/IEC 5230:2020 — Information technology — OpenChain Specification.
- Executive Order 14028 — Improving the Nation’s Cybersecurity (May 2021).
Vulnerability tracking.
- Common Weakness Enumeration (CWE). MITRE Corporation.
- Common Vulnerabilities and Exposures (CVE). MITRE Corporation.
- CVSS v4.0 Specification Document. Forum of Incident Response and Security Teams (FIRST.org), November 2023.
- OpenVEX Specification. OpenSSF.
- CSAF 2.0 — Common Security Advisory Framework. OASIS.
OTA frameworks.
- Uptane Standard for Design and Implementation v2.1.0. Uptane Alliance, Linux Foundation.
- TUF — The Update Framework. Linux Foundation.
- MCUboot Project. Linaro / Apache 2.0.
- Eclipse Hawkbit. Eclipse Foundation.
Industry reference reading.
- Jacobson I., Use Case 2.0: The Hub of Software Development. Ivar Jacobson International, 2011.
- Robertson S. & Robertson J., Mastering the Requirements Process: Getting Requirements Right, 3rd ed., Addison-Wesley, 2012.
- Mavin A., Wilkinson P., Harwood A., Novak M., Easy Approach to Requirements Syntax (EARS), IEEE RE’09, 2009.
- Sommerville I., Software Engineering, 10th ed., Pearson, 2015.
- Watts S. Humphrey, Managing the Software Process, Addison-Wesley, 1989.