Інженерія програмного забезпечення і прошивок для embedded ECUs електросамоката як 29-та 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

20.05.2026 Scootify 15 хв читання

У серії інженерного гайду ми описали акумуляторну батарею з BMS і thermal runaway intro, гальмівну систему, мотор і контролер, підвіску, шини, світло і видимість, раму й вилку, display + HMI, зарядний пристрій SMPS CC/CV, connector + wiring harness, IP-захист, bearingи з ISO 281 L10, стеблину і механізм складання, деку, handgrip + lever + throttle, колесо як assembly, інженерію різьбових з’єднань як joining-axis, термоменеджмент як heat-dissipation axis, EMC/EMI як interference-mitigation axis, кібербезпеку як interconnect-trust axis, NVH як acoustic-vibration-emission axis, функціональну безпеку як safety-integrity axis, інженерію життєвого циклу батареї як sustainability axis, ремонтопридатність як repairability-axis, environmental robustness як environmental-conditioning axis, privacy і захист персональних даних як privacy-preservation axis та інженерію надійності як reliability-prediction meta-axis. Ці 28 engineering-axes описали підсистеми, способи з’єднання, теплові й електромагнітні явища, безпеку, sustainability, ремонтопридатність, environmental conditioning, privacy і reliability-engineering — проте усі вони описували ПЗ опосередковано: ED (functional safety) посилалася на ISO 26262 ASIL-decomposition для ПЗ, DZ (cybersecurity) — на ISO/SAE 21434 TARA, ED і DZ разом — на UN R155/R156, але жодна не описала сам SW-process axis: як firmware embedded ECUs (motor controller + BMS + dashboard + IoT gateway + charger MCU) розробляється, валідується, версіонується, трасується, оновлюється і моніториться на уразливості протягом життєвого циклу.

Software & firmware engineering — це process axis усього e-самоката. Вона надає процесні стандарти (Automotive SPICE 4.0 + ISO/IEC/IEEE 12207:2017 + IEC 62304 + DO-178C reference), технічні стандарти кодування (MISRA C:2023 + AUTOSAR C++14 Coding Guidelines), архітектурні рамки (AUTOSAR Classic Platform R23-11 + AUTOSAR Adaptive Platform R23-11), safety-розширення (ISO 26262-6:2018 SW level + Annex D Freedom from Interference), security-розширення (ISO/SAE 21434:2021 + UN R155 CSMS + UN R156 SUMS), інструменти кваліфікації (ISO 26262-8 Clause 11 + DO-330), формати дистрибуції (CISA SBOM Minimum Elements + SPDX 2.3 + CycloneDX 1.6 + Uptane OTA framework) і протоколи моніторингу (CWE Top 25 + CVE + CVSS v4.0 + VEX + CSAF). Без неї нема відтворюваного і простежуваного способу довести, що той firmware, який зараз працює у ECU вашого e-самоката, відповідає тому самому source code, який пройшов TARA, ISO 26262 review і HALT.

Це двадцять дев’ята engineering-axis deep-dive у серії гайду — і дванадцята cross-cutting infrastructure axis (паралельна до 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, тепер SW-process EP). Як і reliability-axis, SW-axis не має «залізної» реалізації — це процесний шар, що накладається на кожну з 28 попередніх axes (firmware у BMS, motor controller, dashboard, IoT gateway, charger).

1. SW-axis ≠ cybersecurity ≠ functional safety ≠ reliability

SW-engineering, cybersecurity, functional safety і reliability часто плутають — особливо в маркетингу — але вирішують різні задачі і регулюються різними стандартами:

Вимір	SW-engineering (EP)	Cybersecurity (DZ)	Functional safety (ED)	Reliability (EN)
Питання	Як ПЗ розробляється, тестується, оновлюється, трасується?	Що захищає ПЗ від навмисної атаки?	Що станеться при випадковій відмові ПЗ?	Скільки годин до відмови ПЗ?
Артефакт	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
Стандарт-фундамент	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
Інструмент аналізу	V-model + traceability matrix + static analysis + MC/DC	TARA + attack tree + EVITA model	Hazard analysis (HARA) + ASIL-decomposition SW + Annex D FFI	Software reliability growth modeling (Jelinski-Moranda, Littlewood-Verrall)
Технічна ціль	Передбачувано виробити коректне ПЗ	Не пускати зловмисника	Запобігти каскаду при випадковій відмові	Передбачити кількість дефектів за час
Цикл валідації	A-SPICE assessment + audit + SQM	CSMS audit + pen-test	Safety audit + FMEDA + tool qualification	Field MTTF measurement + bug rate trend
Тригер	«Як побудувати?»	«Хто атакує?»	«Що зламається?»	«Коли зламається?»

Класичний приклад розмежування: firmware BMS із ISO 26262-6:2018 Part 6 ASIL D (functional safety axis) і ISO/SAE 21434:2021 CAL 4 (cybersecurity axis). Functional safety забезпечує: при single-bit memory corruption спрацьовує MPU exception, мікроконтролер переходить у failsafe (ICs відкриваються через relay). Cybersecurity забезпечує: жоден прошитий firmware без валідного RSA-PSS signature не запуститься (anti-tamper). Reliability прогнозує: skewed Weibull (β = 0.8 у перший рік — software infant mortality від edge-case race conditions). SW-engineering — це окрема axis, бо вона забезпечує: (a) той самий source code, який пройшов TARA і HARA, фактично потрапляє у production binary через reproducible build; (b) кожна вимога в SRS має тестовий case з підписаним результатом; (c) обнаружений CVE-2026-NNNNN у dependency (наприклад, mbedTLS) тригерить documented патч-pipeline з audit-trail.

Без SW-axis: ISO 26262 і ISO/SAE 21434 і reliability — це папір, не реальність на ECU.

2. Де живе firmware e-самоката: 5 контролерів

Сучасний e-самокат містить до 5 окремих ECUs з firmware’ом, кожна зі своїм toolchain і своїм update-channel:

ECU	Типова MCU/SoC	Firmware-розмір	RTOS / bare-metal	Update-channel	ASIL / CAL
Motor controller	STM32F4/F7 ARM Cortex-M4/M7, GD32F4, Renesas RH850	256 КБ – 2 МБ	FreeRTOS / Zephyr / bare-metal SVPWM-loop	USB-CDC або CAN-bootloader через service-port	ASIL B (PMSM control loop) / CAL 2
BMS controller	TI BQ76952, ADI ADBMS6815/6817, NXP MC33775, STM32L4	128 КБ – 1 МБ	Bare-metal або FreeRTOS	I²C/SPI з motor controller (slave); OTA через MCU host	ASIL D (thermal-runaway prevention) / CAL 3
Dashboard / HMI	STM32H7 + LVGL, NXP iMX RT, Espressif ESP32-S3	1 – 8 МБ (з LVGL + fonts)	FreeRTOS / Zephyr / Apache NuttX	Bluetooth LE OTA від companion app	QM (no safety function) / CAL 1
IoT gateway / telematics	Quectel BG95/EG95 (LTE-M/NB-IoT) + ESP32-S3, Nordic nRF9160	2 – 16 МБ	Zephyr / FreeRTOS / Linux (Buildroot/Yocto for high-end)	Cellular OTA через MQTT-broker або HTTPS	QM (cloud connectivity) / CAL 3-4 (gateway = attack surface)
Charger MCU	STM32G4 (digital SMPS), Microchip dsPIC33CK, TI C2000 F28004x	64 – 512 КБ	Bare-metal (digital control loop 100 кГц)	USB-CDC service-port; рідко OTA	ASIL A-B (IEC 62368-1 SELV/LPS) / CAL 1

Ключове спостереження: ці 5 firmwares не є єдиним моноліт-ПЗ. Це 5 окремих процесорів з 5 окремими toolchain’ами (GCC ARM Embedded, IAR EWARM, Keil MDK, Renesas CS+, Microchip XC16), 5 окремих build-pipeline’ів, 5 окремих SBOM, 5 окремих OTA-каналів і часто 5 окремих поставальників (motor controller від Bosch, BMS від TI reference design + custom layer, dashboard від OEM, IoT gateway від Quectel + custom application, charger від Mean Well або CUI).

Це означає, що SW-engineering для e-самоката — це multi-ECU systems engineering, не single-app development. Питання «яка версія прошивки на вашому самокаті» некоректне — правильне питання: «Motor=v2.3.7, BMS=v1.8.1, Dashboard=v4.2.0, IoT=v5.1.3, Charger=v1.0.5» (5 версій + їх interoperability matrix).

3. ISO/IEC/IEEE 12207:2017 — 30 процесів у 4 групах

ISO/IEC/IEEE 12207:2017 (третя редакція з 1995, harmonised із ISO/IEC/IEEE 15288 systems engineering) — це референсний стандарт лайфциклу ПЗ. Він не приписує конкретної методології (V-model vs Agile vs DevOps), а визначає словник із 30 процесів у 4 групах, з яких будь-який специфічний стандарт (A-SPICE, ISO 26262-6, IEC 62304, DO-178C) бере підмножину і додає вимоги.

Група	Кількість процесів	Приклади	Що відбувається
Agreement processes	2	Acquisition + Supply	OEM e-самоката купує firmware-стек від Tier-1 (Bosch motor controller + Texas Instruments BMS reference + Quectel IoT). Контракт визначає 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	Організація встановлює CI/CD-інфраструктуру, утримує засертифіковані toolchain’и, керує знаннями (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	План проєкту, контроль за відхиленнями, конфіг-менеджмент (Git + branch policy), вимірювання прогресу (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	Власне інженерний core: збір вимог → архітектура → реалізація → integration → V&V → deployment → maintenance

E-самокатний firmware-стек проходить всі 30 процесів для production release: від Agreement (Bosch supply Bosch firmware to OEM під NDA + escrow) до Disposal (як видалити user data при scrapping, див. privacy axis і recycling axis).

4. Automotive SPICE 4.0 — V-model з 6 SWE + 5 SYS + 4 HWE + 4 MLE

Automotive SPICE 4.0 (Process Assessment Model, December 2023, виданий VDA QMC) — це automotive-специфічна профіль-конкретизація ISO/IEC 33001 (Process Assessment) і ISO/IEC 33020 (Process Measurement Framework) із доменом-specifically оцінкою process capability за рівнями 0–5 (Incomplete → Performed → Managed → Established → Predictable → Innovating). OEM (BMW, Mercedes, Volkswagen, Stellantis) зобов’язують Tier-1 (Bosch, Continental, ZF, Aptiv) досягти Capability Level 2 (Managed) для всіх VDA Scope процесів перед SOP (Start of Production).

VDA Scope у A-SPICE 4.0 поділена на Basic Part + Domain Specific Parts (Plug-ins). Basic Part обов’язкова для всіх; з Plug-ins обирається мінімум один:

Part	Process Group	Процеси	Що оцінюється
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-незалежність + 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 (вся 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 (вся 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 (релевантно для e-самокатних camera-based ADAS, lane-keeping vision, fall-detection ML)

Для e-самоката Tier-1 OEM зазвичай вимагає CL2 у Basic + SYS + SWE Plug-ins, інколи CL2 у HWE Plug-in. MLE Plug-in активується лише якщо в скутері є ML-модель (наприклад, pedestrian detection у premium-models з front camera, поки рідкісне для e-scooters, але стандартне в L3-L7 mobility).

V-model A-SPICE 4.0 для SWE-домену виглядає так (зліва-направо — спуск, потім підйом по правій частині 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 ──────────┘

Кожна горизонтальна лінія — це трасування: вимога з SyRS лінкується (Polarion, IBM DOORS, Jama, ReqIF-export) до тестового кейсу у SYS.5; вимога з SRS — до тестового кейсу у SWE.6. Без traceability matrix A-SPICE assessment не пройти.

5. ISO 26262-6:2018 — software level + Freedom from Interference

ISO 26262-6:2018 (Part 6: Product Development at the Software Level) — це safety-overlay над A-SPICE SWE-процесами. Він додає 8 додаткових клозиш (5–12) до базового SW-V-model:

Клозис	Тема	Що вимагається
5	General Topics	Загальні вимоги до SW dev
6	Initiation of Product Development at the Software Level	SW development plan + методи + інструменти
7	Specification of Software Safety Requirements	SwSR derivation з SyRS + ASIL inheritance
8	Software Architectural Design	SwAD з 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

Серцевина — 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.»

Перекладено: якщо BMS firmware містить і ASIL D thermal-runaway monitor, і QM Bluetooth pairing UI — або все має бути розроблене під ASIL D (надмірно дорого, бо MISRA-mandatory rules + 100% MC/DC + double-precision arithmetic + redundancy усюди), або треба продемонструвати FFI і дозволити QM-частині залишатися QM.

Annex D ідентифікує 3 категорії інтерференції, що мають бути блоковані:

Категорія FFI	Що блокується	Технічний механізм
Spatial interference	QM-частина не може корумпувати memory (data/code) ASIL D-частини	MPU (Memory Protection Unit) з ARM Cortex-M, MMU з ARM Cortex-A, OS partition (FreeRTOS-MPU, SAFERTOS, QNX, INTEGRITY-178B); read-only code section, separate stacks
Temporal interference	QM-частина не може забирати CPU-час, не давати ASIL D-таску виконатись up-to-deadline	Static cyclic scheduler (OSEK/AUTOSAR Classic), WCET (Worst Case Execution Time) analysis, watchdog timer, partition scheduler (ARINC 653-style)
Communication interference	QM-частина не може корумпувати дані, які споживає ASIL D	E2E (End-to-End) protection per AUTOSAR (CRC + counter + ID), data integrity check, message authentication code (HMAC або CMAC)

Якщо FFI продемонстровано через MPU + static scheduler + E2E protection — QM Bluetooth UI може лишатися QM, ASIL D thermal-runaway monitor може лишатися ASIL D, обидві частини співіснують у спільному firmware binary. Якщо FFI не продемонстровано — все firmware має бути ASIL D, що для типового BMS firmware із 1 МБ означає 2–5× зростання cost (MISRA mandatory + 100% MC/DC + every line reviewed by independent verifier).

6. MISRA C:2023 — directives + rules + decidability + advisory/required/mandatory

MISRA C (Motor Industry Software Reliability Association C Guidelines) — це coding standard з 1998, який почали як UK automotive industry consortium і який тепер де-факто mandatory у всіх ISO 26262 safety-critical SW і у багатьох aerospace + medical contexts.

Поточна редакція — MISRA C:2023, опублікована в березні 2023, консолідує:

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 (повна підтримка C11/C18 + atomics + threads)
Technical Corrigendum 1 + Technical Corrigendum 2

MISRA C:2023 має 2 категорії guidelines з різним статусом:

Категорія	Кількість (приблизно)	Як перевіряти	Приклад
Directives	17	Манульний review, бо алгоритм не може довести compliance із source code	«Dir 1.1: Any implementation-defined behaviour on which the output of the program depends shall be documented and understood» — потребує читання компайлер-документації
Rules	175+	Static analysis tool може перевіряти автоматично (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» — tool аналізує всі call sites

Кожна rule додатково класифікована як Decidable vs Undecidable:

Тип	Що це значить	Приклад
Decidable	Існує алгоритм, що дає yes/no для кожного source code	«Rule 14.1: A loop counter shall not have essentially floating type» — простий syntactic check
Undecidable	Halting-problem-level — алгоритм не може гарантувати correct yes/no для всіх програм	«Rule 18.1: A pointer resulting from arithmetic on a pointer operand shall address an element of the same array as that pointer operand» — потребує full alias analysis, NP-hard у загальному

Для undecidable rules static analysis tool видає best-effort результати з false positives / false negatives; MISRA Compliance:2020 (окремий документ) визначає, як OEM/Tier-1 декларують compliance із undecidable rules через deviation procedure (документований відступ із технічним обґрунтуванням).

Окрім decidability, кожна guideline має enforcement category:

Category	Зміст	Як OEM ставиться
Mandatory	Compliance обов’язкова, deviations не дозволені	Кожна violation = blocker bug
Required	Compliance обов’язкова, але deviations дозволені з документацією + justification	Tier-1 робить deviation form, OEM safety team review-ить
Advisory	Compliance рекомендована, deviations не потребують документації	Можна ігнорувати, але якщо ввімкнено в tool config — варто слідувати

Для типового BMS firmware з ~100k LOC C компанії очікують 0 mandatory violations + ≤50 required deviations + N advisory violations перед release. Це reflective standard automotive practice: 100% mandatory compliance, документовані deviations для required, advisory як guideline.

7. AUTOSAR Classic Platform R23-11 vs Adaptive Platform R23-11

AUTOSAR (AUTomotive Open System ARchitecture) — це partnership-консорціум OEM + Tier-1 (BMW, Bosch, Continental, Mercedes-Benz, PSA, Toyota, Volkswagen та інші), що стандартизує software architecture для automotive ECUs з 2003. Сучасні релізи виходять двічі на рік за формулою Rxx-yy (рік-місяць). На травень 2026 актуальні: AUTOSAR CP R23-11 (Classic Platform) і AUTOSAR AP R23-11 (Adaptive Platform).

Аспект	AUTOSAR Classic Platform (CP)	AUTOSAR Adaptive Platform (AP)
Тип ECU	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
Архітектура	3-layer: Application → RTE → Basic Software (BSW) → MCAL → MCU	Service-Oriented Architecture (SOA) із ARA (AUTOSAR Runtime for Adaptive Applications) на POSIX OS
Тип configuration	Static, build-time (ARXML → code generation → linked binary)	Dynamic, runtime service discovery
Communication	CAN/CAN FD/LIN/FlexRay/Ethernet через COM stack	SOME/IP Service Discovery + DDS + ROS2
OS	OSEK/VDX (now AUTOSAR OS) із fixed-priority preemptive scheduler	POSIX-compatible (PSE51 profile) — Linux, QNX, INTEGRITY-178B
Pertinent для e-самоката	Motor controller, BMS, charger MCU, simpler dashboards	IoT gateway, premium dashboards з navigation/AR, future autonomy stack
Тип ASIL/CAL coverage	Up to ASIL D	Up to ASIL B сьогодні (storage/POSIX обмеження), 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) — це формальна модель усього стеку: SWCs, runnables, RTE-events, BSW configuration. Tools (Vector DaVinci Developer, EB tresos, Mentor Volcano) генерують RTE-код і BSW-config із ARXML.

Для e-самоката Classic Platform — overkill для більшості (license cost від $50–200k/proj), але OEM-Tier-1 контракти часто зобов’язують AUTOSAR Classic для motor controller + BMS, бо інакше не вписуються у Tier-1 production toolchain.

8. ISO/SAE 21434:2021 + UN R155 CSMS — TARA у SW context

ISO/SAE 21434:2021 (Road vehicles — Cybersecurity engineering, серпень 2021) — спільне видання ISO TC22/SC32 і SAE Vehicle Cybersecurity Systems Engineering. На відміну від ISO 26262 (random/systematic faults), ISO/SAE 21434 розглядає навмисні атаки.

Стандарт організовано у 15 клозиш, з ключовими:

Клозис	Тема
5	Overall cybersecurity management
6	Project-dependent cybersecurity management
7	Distributed cybersecurity activities (між OEM і 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) — це core методологія 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 дає Cybersecurity Goals (high-level security properties), які поступово розкладаються у Cybersecurity Claims і Cybersecurity Controls (конкретні технічні механізми). CAL 1–4 (від найнижчого до найвищого) визначає рекомендований ступінь rigor аналогічно до ASIL у functional safety.

Важлива примітка про scope: ISO/SAE 21434 формально виключає two-wheelers у scope text, бо L-category transport регулюється окремо UNECE WP.29 GRBP. Однак для e-самоката як L1e-A / L1e-B / L3e (за EU 168/2013 framework regulation) UN R155 (Cyber Security and CSMS) обов’язково з грудня 2027 для нових типів і червня 2029 для існуючих. ISO/SAE 21434 — це методологічна базова лінія для виконання вимог UN R155. На практиці e-scooter OEM використовують ISO/SAE 21434 TARA workflow як технічну реалізацію CSMS-claims.

Детальний розбір threat modeling, attack surfaces, EVITA model і pen-testing — у interconnect-trust axis (cybersecurity). Тут ми фокусуємось на SW-engineering інтеграції TARA: кожна Cybersecurity Claim із Clause 9 повинна мати traceability link до конкретного коду, тесту і SBOM-component, що її реалізує.

9. UN R156 SUMS — Software Update Management System

UN R156 (UNECE Regulation No. 156 — Software Update and Software Update Management System) — це регуляторна вимога WP.29 (World Forum for Harmonization of Vehicle Regulations), яка зобов’язує OEM мати документований процес для:

Видання software оновлень (включно з definition того, що означає software update vs calibration update vs content update)
Track’інгу того, які vehicles мають яку software version
Перевірки compatibility перед update (наприклад, BMS firmware v1.8.1 потребує motor controller firmware ≥ v2.3.5, а не v2.2)
Demonstrating impact оновлення на (a) type approval relevance — чи це новий vehicle type? (b) safety — чи це впливає на UN R157 ALKS, UN R79 steering? (c) cybersecurity — чи закриває це CVE? (d) emissions — чи впливає на Euro X compliance?
Authentication, integrity, rollback protection для самого update process
Driver / user notification при необхідності (наприклад, у UI на dashboard «Update available, restart required, charged ≥ 50%»)
Record-keeping про кожну ECU + кожну versionу + кожен update event протягом життя vehicle (мінімум 10 років після SOP)

Vehicle Category	UN R155/R156 нові типи з	UN R155/R156 існуючі типи з
M, N (passenger cars + trucks)	Липень 2022	Липень 2024
O (trailers + semi-trailers, electronic systems тільки)	Липень 2022	Липень 2024
L (motorcycles, e-scooters, e-bikes — L1e, L3e, L6e, L7e)	Грудень 2027	Червень 2029

Для e-самоката L1e-A (slow electric bicycle, ≤ 25 км/год) до L3e (high-power e-scooter, > 35 км/год, > 11 kW) — UN R156 SUMS стане обов’язковим із грудня 2027 для нових типових затверджень.

Структура SUMS (на практиці):

Компонент SUMS	Технічна реалізація
Software identification	Unique software ID per ECU (наприклад, BMS-v1.8.1-build42-sha256:abcd…); зберігається у ECU NVM + reported у service tool
Vehicle interdependency database	OEM cloud DB, що мапить VIN → set of (ECU, version) tuples
Compatibility matrix	Перед допуском update: cross-check, що нова combination (ECU1=v1.8.2, ECU2=v2.3.7, …) була validated офіційно
Update authentication	Signed binary (RSA-PSS-2048 / RSA-PSS-3072 / ECDSA-P-256) із trust-chain до OEM root CA
Integrity check	SHA-256 hash of binary, signed within manifest
Rollback protection	Monotonic counter incremented per release, stored у 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 допустимо)	Залежно від impact — safety-critical update може бути forced; non-safety — opt-in
Audit trail	Every update attempt (success / fail / aborted) логується із VIN + ECU + from-version + to-version + timestamp + outcome
Post-update verification	Kid-test: чи ECU boot’ається? чи self-test pass? чи communication з іншими ECUs справна? якщо не — rollback до попередньої версії

De facto реалізація для L-category e-самоката: Uptane framework (described § 15) забезпечує більшість cryptographic vehicle-side вимог, а cloud-side OEM розгортає TUF (The Update Framework) repositories із Director і Image roles. Open-source реалізації: 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) — це машино-читабельний список усіх programs components у firmware: imports, libraries, dependencies, transitive dependencies до n-rd рівня. Для embedded ECU це може бути 200–500 records (типовий FreeRTOS-based BMS firmware містить FreeRTOS kernel + mbedTLS + lwIP + STM32 HAL + STM32 LL + custom application code + кілька дрібних helper libs).

SBOM відповідає на питання: «Чи цей firmware містить версію X library Y, у якій відкритий CVE-Z?» — без необхідності reverse-engineer’ити binary.

Регуляторна основа: U.S. Executive Order 14028 (травень 2021, «Improving the Nation’s Cybersecurity») вимагає SBOM для federal software. NTIA опублікувала «The Minimum Elements For a Software Bill of Materials (SBOM)» у липні 2021, що визначає 7 baseline data fields. CISA (Cybersecurity and Infrastructure Security Agency) перейняла стандарт у 2023, а у 2025 опублікувала draft update із 3 додатковими полями:

Поле (NTIA 2021)	Опис
Supplier Name	Postачальник компонента (наприклад, «STMicroelectronics» для STM32 HAL)
Component Name	Назва компонента («STM32CubeF4 HAL Driver»)
Version of the Component	SemVer чи vendor-specific («v1.27.4», або git commit hash)
Other Unique Identifiers	PURL (Package URL), CPE (Common Platform Enumeration), SWID tag, або internal SKU
Dependency Relationship	Який компонент depends on який
Author of SBOM Data	Хто згенерував цей SBOM (OEM Tier-1, vendor self-attestation, third-party)
Timestamp	When SBOM було згенеровано (важливо для vulnerability matching)

Поле (CISA 2025 draft, додатково)	Опис
Component Hash	Cryptographic hash (SHA-256 minimum) для binary identification
License	SPDX-License-Identifier (наприклад, `MIT`, `Apache-2.0`, `GPL-3.0-or-later`) для legal compliance
Tool Name	SBOM-generation tool (Syft, Trivy, ScanCode, custom) для reproducibility
Generation Context	Build-time / source / binary / deployment (де SBOM було згенеровано в lifecycle)

Формати:

Формат	Origin	Strength
SPDX 2.3 / 3.0	Linux Foundation, ISO/IEC 5962:2021	License-centric, mature, ISO-standardized
CycloneDX 1.6	OWASP	Security-centric, native VEX support, BOM-Link
SWID Tags	ISO/IEC 19770-2:2015	Asset-management origin; CISA 2025 deprecates

Для embedded ECU firmware best practice: CycloneDX 1.6 JSON з повним enumerated dependencies, attached at firmware release як .cdx.json у тій самій директорії як .bin. OEM cloud зберігає SBOM per ECU per version і matchить проти live CVE feed (NVD) для proactive vulnerability disclosure.

11. Vulnerability tracking — CWE + CVE + CVSS v4.0 + VEX + CSAF

Знання «у firmware є компонент mbedTLS v3.4.1» — це SBOM. Знання «у mbedTLS v3.4.1 є CVE-2024-23170 ECDSA timing side-channel із CVSS 5.9» — це vulnerability management. Чотири стандартні артефакти:

Артефакт	Origin	Що описує
CWE (Common Weakness Enumeration)	MITRE, NIST SP 800-126	Класи weakness’ів (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 — щорічно оновлюваний ranking найчастіших CWE у CVE feed
CVE (Common Vulnerabilities and Exposures)	MITRE-managed, CNAs (CVE Numbering Authorities)	Конкретні екземпляри: CVE-YYYY-NNNNN із вказівкою vendor + product + version + CWE clause + reference
CVSS v4.0 (Common Vulnerability Scoring System)	FIRST.org, publish 1 листопада 2023	Severity score 0.0–10.0 (None/Low/Medium/High/Critical) на основі 4 metric groups
VEX (Vulnerability Exploitability eXchange) / OpenVEX / CSAF	OASIS CSAF + OpenSSF OpenVEX	Status statement: «CVE-X у component Y у нашому продукті — NOT_AFFECTED (because reason)» або «AFFECTED + remediation pending until date Z»

CVSS v4.0 — поточна редакція, що заміняє CVSS v3.1 (2019). Зміни:

Metric Group	CVSS v3.1	CVSS v4.0 (нова)
Base	AV/AC/PR/UI + S + CIA	AV/AC/AT (Attack Requirements нове) + PR/UI + VC/VI/VA (Vulnerable system Confidentiality/Integrity/Availability) + SC/SI/SA (Subsequent system)
Temporal → Threat	E/RL/RC	E (Exploit Maturity) only — спрощено
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

Safety supplemental metric у CVSS v4.0 — спеціально для cyber-physical systems (включно з e-самокатами): «Чи може exploit цього vulnerability спричинити physical safety harm?» Цінне для e-scooter: якщо CVE у motor controller firmware дозволяє remote brake disable — Safety: Present, що піднімає priorиty повз чистий information-security CVSS score.

Workflow:

SBOM published із 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

Якщо при розробці безпеково-критичного ПЗ використовується tool (compiler, static analyzer, model-based tool, code generator) — потрібно довести, що tool сам по собі не вносить помилок у вихідний artifact. Це tool qualification, описана у ISO 26262-8:2018 Clause 11.

Tool Confidence Level (TCL) обчислюється з двох inputs:

Input	Шкала	Значення
Tool Impact (TI)	TI1 / TI2	TI1: malfunction не може спричинити safety violation (наприклад, formatter ide). TI2: може (наприклад, compiler)
Tool Error Detection (TD)	TD1 / TD2 / TD3	TD1: висока ймовірність виявлення помилки tool’а downstream (compile + unit test). TD2: середня. TD3: низька (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	Що вимагається
TCL1	Tool можна використовувати без qualification (не впливає на safety)
TCL2	Tool потребує qualification одним із 4 методів
TCL3	Tool потребує qualification одним із 4 методів (та ж сама опція, але stricter rigor)

4 методи qualification (Clause 11.4.6):

Метод	Опис	Приклад
1a	Increased confidence from use	Tool використовується OEM industry-wide ≥ 1 рік без incident
1b	Evaluation of tool development process	Сам tool розроблений під ISO 26262 (recursive)
1c	Validation of the tool	OEM перевіряє кожен release tool’а тестовим набором, що покриває usage
1d	Development in accordance with safety standard	Tool розроблений vendor під ISO 26262 з нуля

Практика: для motor controller firmware під ASIL D, типові qualified tools:

Compiler: GCC ARM Embedded — arm-none-eabi-gcc — TÜV SÜD certified release. Або IAR Systems EWARM із SafetyDoc package. Або Tasking VX-toolset.
Static analyzer: LDRA Testbed, Coverity Polaris, Perforce Helix QAC, Polyspace Bug Finder — TÜV-certified для ISO 26262 use.
Code coverage: VectorCAST, LDRA Testbed coverage, Squore.
Model-based code generator: MathWorks Simulink Embedded Coder із DO-178C / ISO 26262 Tool Qualification Kit.

Qualification artifacts (Tool Safety Manual, Tool Operating Conditions, Tool User Guide) поставляються vendor’ом разом із tool’ом і входять у safety case того firmware’а.

13. ISO/IEC/IEEE 29148:2018 + EARS — requirements engineering

ISO/IEC/IEEE 29148:2018 (Systems and software engineering — Life cycle processes — Requirements engineering) — це стандарт як писати вимоги. Він покриває весь requirements lifecycle: elicitation → analysis → specification → verification → validation → management.

Стандарт визначає 3-рівневу ієрархію документів (відповідно до A-SPICE SYS.1 → SYS.2 → SWE.1):

Документ	Зміст	Хто пише	Хто читає
StRS (Stakeholder Requirements Specification)	Що користувач хоче (use cases, business needs, regulatory)	Marketing + Product management + Compliance	Product team
SyRS (System Requirements Specification)	Що система робить (functional + non-functional, hardware + software inclusive)	Systems engineer	SW + HW + MechE teams
SRS (Software Requirements Specification)	Що ПЗ робить (per ECU)	Software architect	Software developers + Test engineers

EARS (Easy Approach to Requirements Syntax) — це нотація написання вимог, що знижує ambiguity. 5 patterns:

Pattern	Шаблон	Приклад для 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.

EARS-формульована вимога легше пройти через automated requirement-quality checker (Visure, Polarion, IBM ELM) і трасується назад до single test case без двозначності.

14. ISO/IEC 25010:2023 — 8 characteristics product quality model

ISO/IEC 25010:2023 (Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality model) — це таксономія non-functional вимог. Заміняє ISO/IEC 9126 від 2001 і ISO/IEC 25010:2011.

Characteristic	Sub-characteristics	E-scooter relevance
Functional Suitability	Completeness + Correctness + Appropriateness	Чи реалізовано всі вимоги SyRS? Чи коректно?
Performance Efficiency	Time behaviour + Resource utilization + Capacity	Motor control loop ≥ 20 кГц, CPU < 70%, RAM < 80%
Compatibility	Coexistence + Interoperability	Сусідній firmware на ECU не падає при concurrent OTA
Interaction Capability (NEW у 2023, заміняє Usability)	Appropriateness recognizability + 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 + Analyzability + Modifiability + Testability	OTA partition layout, log granularity, on-target debugger access
Flexibility (NEW у 2023, заміняє Portability)	Adaptability + Scalability + Installability + Replaceability	Cross-MCU portability via HAL, A/B partition support, OTA install resume
Safety (NEW у 2023)	Operational constraint + Risk identification + Fail safe + Hazard warning + Safe integration	Per ISO 26262 + UNECE GTR 22

E-scooter SQM (Software Quality Management) team складає Quality Plan, що мапить кожне sub-characteristic до measurable metric і acceptance criterion перед release.

15. OTA bootloader: A/B partition + secure boot + rollback protection + Uptane

OTA update реалізується на ECU через primary bootloader → secondary update bootloader → application з A/B partition layout:

Flash memory layout (typical STM32F4, 1 МБ Flash):

0x08000000 ┌─────────────────────────────┐ Primary Bootloader (16 КБ)
           │ 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 КБ)                     │ Validates signature of application
           │ — header parsing            │ Manages A/B swap
           │ — signature verification    │ Anti-rollback counter check
           │ — OTA staging               │
0x08014000 ├─────────────────────────────┤
           │ Application Slot A (464 КБ) │ Current firmware image
           │ — header: version + hash    │
           │ — image binary              │
           │ — signature (ECDSA-P-256)   │
0x08088000 ├─────────────────────────────┤
           │ Application Slot B (464 КБ) │ Next firmware image (or previous, post-swap)
           │ — same layout as Slot A     │
0x080FC000 ├─────────────────────────────┤
           │ NVM / Config / Logs (16 КБ) │ Persistent state
0x080FFFFF └─────────────────────────────┘

Update flow (Uptane-compliant):

Download — IoT gateway pulls signed image manifest з Director repository (per-vehicle, ephemeral) + image z Image repository (CDN, immutable). Manifest містить hash + signature + version + ECU target.
Manifest verification — secondary bootloader verifies manifest signature з Director public key (TUF Targets role).
Image verification — image hash matchить hash з manifest; image signature (ECDSA-P-256 over SHA-256) verifies з vendor public key (TUF Targets role).
Rollback check — image version counter > current monotonic counter? Якщо ні — refuse. Counter зберігається у HSM / SHE / OTP fuse, не може бути reset’ed software-only.
Staging — image written до inactive partition (якщо зараз boot’имось із A, пишемо у B).
Atomic swap — після write complete + verification, NVM-prerequisite-flag set’иться до «boot from B» (single-write atomic flip).
Reboot — primary bootloader reads flag, jumps to B.
Post-boot validation — secondary bootloader runs self-test (peripheral init, communication check, internal consistency). Якщо pass — confirm boot success (rollback counter advanced). Якщо fail протягом N seconds — primary bootloader detects watchdog reset, flips flag back до «boot from A», recovery.

Secure boot стек (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: secondary bootloader signature з vendor root CA
   ▼
Secondary update bootloader
   │ verifies: application signature з 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) — це OTA framework спеціально для автотранспорту, narрозвинутий з TUF (The Update Framework). Ключове розширення TUF — Director repository (per-vehicle ephemeral manifests, що binду versions до VIN + ECUs у tamper-resistant спосіб). Open-source реалізації: aktualizr (HERE Technologies, тепер Foundries), Uptane Standalone Verification Library, Eclipse Hawkbit Update Server.

Альтернативи (poза Uptane):

MCUboot (Linaro Project) — secure bootloader для embedded MCU, native AB-swap + image signing. Підтримує Arm Cortex-M, RISC-V, Xtensa. Open-source Apache-2.0.
AUTOSAR Classic Flash Bootloader — proprietary, integrated с AUTOSAR Diagnostic stack (UDS ISO 14229). Зазвичай vendor’ом (Vector, ETAS, EB).
systemd-boot + dm-verity + casync — Linux-based для high-end IoT gateways (e.g., Nvidia Jetson Nano для AR navigation HUD).

16. Cross-axis matrix: SW concept × 28 existing engineering axes

SW-engineering — meta-axis, тому кожна попередня engineering axis має SW-аспект. Matrix mapping концепту до axis:

Engineering axis	SW-relevance
DT Joining / fasteners	Жодного firmware-aspect — purely mechanical. SW-irrelevant.
DV Heat dissipation / thermal	Motor controller derating algorithm у firmware: temperature → current limit lookup table
DX Interference / EMC	Watchdog refresh strategy при EMI-induced single-bit flip; CRC on all CAN frames
DZ Cybersecurity	TARA → cybersecurity claims → SRS items → SWE.3 implementation → SWE.6 test. Прямий integration
EB NVH	Motor SVPWM tuning у firmware впливає на acoustic emission spectrum (10 кГц SVPWM tone)
ED Functional safety	ASIL allocation → ISO 26262-6 SW-process → SWE.3 із MISRA C — прямий overlay
EF Sustainability / lifecycle	Coulomb counter calibration у BMS firmware визначає accuracy SoH estimation для secondary use
EH Repairability	Service tool API (UDS ISO 14229 у CAN, JTAG/SWD-protected по password) — firmware exposes
EJ Environmental robustness	Temperature compensation algorithm у firmware (drift у sensor reading vs T)
EL Privacy	Telemetry minimisation у IoT gateway firmware; consent management у dashboard UI
EN Reliability	Software reliability growth model (Musa-Okumoto, Goel-Okumoto); bug density per KLOC; field MTTF SW
Battery + BMS	BMS firmware: cell balancing algorithm, SoC/SoH estimation Kalman filter, contactor logic
Brake system	Brake-by-wire firmware (rare на e-scooter), ABS algorithm (где є)
Motor + controller	SVPWM, FOC (Field Oriented Control), torque ripple compensation, PMSM commutation
Suspension	Semi-active suspension control (rare на e-scooter, але CycleBoard premium models)
Tyre	TPMS firmware (де є): pressure sampling rate, low-pressure alarm threshold
Lighting / visibility	LED PWM dimming, brake light timing logic, indicator pattern generator
Frame / fork	Жодного firmware — purely mechanical.
Display / HMI	LVGL / TouchGFX framework, UI state machine, font rendering, animation engine
Charger SMPS	CC/CV state machine у charger MCU firmware, hand-shake з BMS over communication line
Connectors / wiring harness	Firmware-side: line-fault detection, redundant signal coverage
IP protection	Firmware-side: humidity sensor monitoring (де є), condensation alarm
Bearings	Жодного 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 у firmware; lever debounce algorithm
Wheel / rim / spoke	Жодного firmware — purely mechanical.
Acceleration + throttle control	Throttle map (linear / progressive / sport), max acceleration limiter
Regenerative braking	Regen current ramp algorithm у motor controller firmware

11 з 28 axes (joining, frame, bearings, wheel + 7 «hard» механічних) не мають firmware-aspect — це чиста механіка. 17 з 28 мають прямий firmware-overlay. SW-axis на практиці інтегрується найтісніше з ED (functional safety), DZ (cybersecurity), Motor + controller, BMS, Dashboard.

17. 7-крокова DIY-практика SW-гігієни для власника

Власник e-самоката не має toolchain’а для firmware development, але може підтримувати SW-гігієну:

Запишіть всі версії. При покупці і після кожного service — запитайте у dealer’а: «Які поточні firmware-версії на motor controller, BMS, dashboard, IoT gateway, charger?» Зафіксуйте у service book. Без цього неможливо знати, чи закриті recent CVE.
Слідкуйте за recall + OTA notifications. OEM публікують safety / cybersecurity bulletins (UN R155 Clause 8 Continual cybersecurity activities). Підписуйтеся на email-канал виробника.
Не блокуйте OTA. Якщо dashboard показує «Update available» — не відкладайте надовго. UN R156 forced-update для critical security CVE законний у L-category з 2027.
Перевіряйте джерело перед manual flash. Якщо ви тюнер і робите custom firmware — переконайтеся, що source — verified GitHub repo з GPG-signed commits. Не flash’те binary з anonymous Telegram-каналу — це класична supply-chain атака.
Зберігайте recovery firmware. До custom-modification — збережіть OEM image на SD-card. UN R156 SUMS у виробників мав би це робити автоматично, але не всі small-brand OEM compliant.
Перевіряйте сертифікати. Service tool (наприклад, Ninebot Diag, KingSong service tool) — якщо просить admin password для firmware update — не давайте без verification з OEM. Багато pseudo-service-tools — це malware із dump’ом firmware для analysis.
Документуйте incidents. Якщо firmware веде себе дивно (random reboots, motor cut-off without cause, dashboard freeze) — записуйте timestamp + circumstances + last known firmware version. Це дозволить dealer’у швидше correlate з known CVE або bug.

18. Recap: SW-axis у 10 пунктах

SW-engineering — це process axis усіх інших axes. Без неї ISO 26262 + ISO/SAE 21434 + ALT/HALT — папір, не реальність.
5 ECUs у типовому e-самокаті: motor controller + BMS + dashboard + IoT gateway + charger. 5 firmwares, 5 toolchains, 5 SBOM, 5 update channels.
ISO/IEC/IEEE 12207:2017 — лайфцикл-каркас із 30 процесів у 4 групах. Automotive SPICE 4.0 — automotive-конкретизація з SYS/SWE/HWE/MLE plug-ins. CL2 очікувано перед SOP.
ISO 26262-6:2018 Clause 7.4.10 + Annex D — Freedom from Interference: spatial (MPU) + temporal (scheduler + WCET) + communication (E2E protection) обов’язкові для mixed-ASIL firmware.
MISRA C:2023 — coding standard для C: directives + rules, decidable + undecidable, mandatory + required + advisory. Zero mandatory violations expected.
AUTOSAR Classic Platform R23-11 для deeply-embedded MCUs (motor controller, BMS, charger); Adaptive Platform R23-11 для high-performance ECUs (IoT gateway).
ISO/SAE 21434:2021 + UN R155 — TARA → CSMS → Cybersecurity Claims trace до SW. UN R156 SUMS — обов’язковий для L-category з грудня 2027 для нових типів.
SBOM per CISA Minimum Elements 2025 — 11 fields (7 NTIA 2021 baseline + 4 нових CISA: hash + license + tool + context). Формат SPDX 2.3 або CycloneDX 1.6.
CVE + CVSS v4.0 — vulnerability tracking. Safety supplemental metric — спеціально для cyber-physical systems. VEX + CSAF — статусні artifacts. Per-CVE patch SLA defined у CSMS.
OTA + secure boot + A/B partition + rollback protection + Uptane framework — defense-in-depth для firmware integrity. HSM/SHE root of trust → secondary bootloader → application chain. Monotonic counter блокує anti-rollback атаки.

SW-axis робить усі попередні engineering axes відтворюваними: той самий firmware, який пройшов TARA + ISO 26262 review + ALT, гарантовано опинився у ECU після production line, OTA update, або field repair. Без SW-axis — engineering corpus залишається теорією на папері; з SW-axis — він стає реальністю на flash chip e-самоката, що ви тримаєте в руках.

Джерела

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.

Cybersecurity standards.

Coding standards.

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.