Інженерія управління конфігураціями електросамоката як 34-та engineering axis: configuration-discipline meta-axis — ISO 10007:2017 + IEEE 828:2012 + SAE EIA-649C + DO-178C SCM + ISO 26262-8 + ITIL 4 + CMMI v2.0 + NIST SP 800-128

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, software & firmware engineering як SW-process axis, human factors і ергономіку як human-machine fit axis, інженерію якості виробництва як manufacturing-process axis, інженерію управління ризиками як risk-anticipation meta-axis та інженерію верифікації і валідації як verification-validation meta-axis. Ці 33 engineering-axes описали підсистеми, способи з’єднання, теплові й електромагнітні явища, безпеку, sustainability, ремонтопридатність, environmental conditioning, privacy, reliability prediction, SW-process, human-machine fit, manufacturing process, risk anticipation та verification + validation. Verification (EX) каже, чи побудовано продукт правильно. Але це лишає окреме питання: «який саме продукт у нас у руках — bit-exact specifically — і як ми це знаємо за рік, за п’ять років, після третьої OTA, після перепаювання контролера?» Жодна з 33 попередніх axes це питання прямо не закрила.

Configuration management (CM) engineering — це configuration-discipline meta-axis усього e-самоката. Вона надає guideline-level meta-standard (ISO 10007:2017 Quality management — Guidelines for configuration management — non-prescriptive guidance над усіма іншими CM standards, aligned з ISO 9001:2015 clause 8.5.2 ідентифікації і простежуваності), systems-and-software engineering CM standard (IEEE 828-2012 Standard for Configuration Management in Systems and Software Engineering — мінімальні вимоги до CM processes, CM Plan structure, life-cycle integration), national consensus standard (SAE EIA-649C:2019 Configuration Management Standard — 5 CM функцій + 37 принципів, governmental + industrial + commercial neutral; EIA-649-1A:2020 Configuration Management Requirements for Defense Contracts — defense overlay), domain-specific high-assurance standards (DO-178C airborne software Section 7 + Table A-8 з 6 SCM objectives applicable до software level A/B/C/D; ISO 26262-8:2018 automotive functional-safety supporting processes — clause 7 configuration management + clause 8 change management + clause 9 verification + clause 10 documentation), IT-service framework (ITIL 4 Service Configuration Management practice + CMDB Configuration Management Database + CMS Configuration Management System), process-maturity model (CMMI v2.0 Configuration Management practice area з 2 capability levels), і security-focused overlay (NIST SP 800-128 Guide for Security-Focused Configuration Management of Information Systems — SecCM, supporting NIST SP 800-53 CM control family).

Це тридцять четверта engineering-axis deep-dive у серії гайду — і сьома process meta-axis (паралельна до reliability-prediction EN + SW-process EP + human-machine-fit ER + manufacturing-process ET + risk-anticipation EV + verification-validation EX, тепер configuration-discipline EZ). Як і всі шість попередніх process meta-axes, CM axis не має «залізної» реалізації — це discipline, що визначає, як systematically знати, що саме встановлено, довести це postfactum, і змінювати це контрольовано. Без CM specifications BOM revision, firmware version (BMS + ESC + display + app), serial-number-to-build mapping, recall scope (which units actually carry the defective component), warranty BOM (what spare parts are interchangeable), і навіть OTA rollback integrity лишаються paper claims — не traceable engineering records.

1. CM ≠ V&V ≠ change request: окрема axis

V&V (axis EX) відповідає на «Are we building the product right + the right product?» Це methodology, що довести conformance + fitness. Change request / ECR / ECO (engineering change request / engineering change order) — це інструмент, не methodology. CM engineering задає окрему discipline, що відповідає на чотири principal questions, які жодна з вище не закриває:

  1. Identification — «Що у нас тут? Як ми назвали кожну окрему частину (CI — Configuration Item) такою, щоб можна було посилатись на неї однозначно через 10 років після disposal? Які baselines ми зафіксували — функціональну, розподілену, продуктову?»
  2. Change control — «Хто ухвалив яку зміну, коли, з яким обґрунтуванням, з якою impact-analysis, і які наслідки для всіх affected baselines, supplier contracts, certifications, warranties?»
  3. Status accounting — «Який статус кожного CI зараз — released, work-in-progress, obsoleted, recalled? Яка найновіша approved revision? Що ще треба зробити, щоб baseline закрилась?»
  4. Verification + audit — «Чи реальний фізичний + цифровий продукт відповідає документації? FCA — функціональний аудит конфігурації; PCA — фізичний аудит конфігурації.»
ВимірV&V engineering (EX)Risk management (EV)Configuration management (EZ)
ТригерStage gate / acceptanceStrategic decision / project initiationLifecycle continuous — кожна зміна
OutputV&V report (test results + reviews + traceability)Risk register + treatment planCMP + CI catalog + baselines + change log + audit reports
StandardIEEE 1012:2016 + ISO/IEC/IEEE 29119ISO 31000:2018 + ISO/IEC 31010:2019ISO 10007:2017 + IEEE 828-2012 + SAE EIA-649C:2019
QuestionDid we build it right? Did we build the right thing?What risks exist + how to treat?What exactly do we have, how do we know, and how do we change it?
GranularityEach life-cycle stage + each integrity levelEnterprise + project + operationalEach CI × each version × each unit

Critical observation: можна мати повноцінне V&V + 0% CM — тести проходять для prototype, але serial-number-to-build mapping не існує, тож коли через 6 місяців 1 з 10 000 units у полі починає evidently overheat, неможливо встановити, чи цей конкретний unit мав той же BMS firmware version + той же cell supplier batch як prototype, що пройшов V&V. Без CM ні reliability-prediction (axis EN), ні risk-treatment (axis EV), ні V&V-evidence (axis EX) не прив’язуються до конкретного фізичного unit у руках конкретного user’а. CM — це substrate, що робить усі попередні axes operationally meaningful.

2. ISO 10007:2017 — guideline foundation

ISO 10007:2017 Quality management — Guidelines for configuration management — опублікований March 2017 як 3rd edition (попередні 1995, 2003); підготовлений ISO/TC 176 Quality management and quality assurance, Subcommittee SC 2 Quality systems (та сама working group що ISO 9001:2015, ISO 9000:2015 vocabulary, ISO 9004:2018). Це guidance standard (не certifiable, не requirements standard) — рекомендована reference для організацій, які хочуть інтегрувати CM у ISO 9001-сумісний QMS.

ISO 10007:2017 — non-prescriptive: не вимагає конкретних tools, не диктує specific approach, не задає mandatory templates. Натомість дає guidance на:

  1. Responsibilities — рекомендована distribution responsibilities між management, project, supplier, configuration manager, change control board (CCB), configuration auditor.
  2. Configuration management process — описує 5 ключових activities (planning + identification + change control + status accounting + audit) узгоджено з SAE EIA-649C 5 CM functions.
  3. Configuration management plan (CMP) — recommended content areas (scope + roles + tools + procedures + records).
  4. Configuration item identification — recommended granularity criteria (CIs of significant cost, complexity, safety, regulatory criticality).
  5. Baselines — recommendation, що baselines документуються + freezed + change-controlled.
  6. Change control + change request — recommended workflow.
  7. Status accounting — recommended records.
  8. Audit — recommended types (functional, physical).

ISO 10007:2017 — default starting point для організацій, що ще не мають CM системи. Для організацій у regulated domains (aerospace DO-178C, automotive ISO 26262, medical FDA QSR) ISO 10007:2017 виступає complementary — domain-specific standard диктує what, ISO 10007:2017 дає how (рекомендована structure + workflow). Не замінює EIA-649C для defense contracts, IEEE 828 для systems/software engineering, або ISO 26262-8 для automotive safety. Aligned з ISO 9001:2015 clause 8.5.2 (identification and traceability) — ISO 9001 вимагає identification + traceability, ISO 10007 деталізує як це здійснити.

3. IEEE 828-2012 — CM standard for systems and software engineering

IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering — опублікований 16 March 2012, sponsored IEEE Computer Society Software & Systems Engineering Standards Committee (S2ESC). Це requirements standard (на відміну від guidance ISO 10007) — встановлює мінімальні вимоги до CM processes для будь-якої форми, класу, типу software або system.

Ключові вимоги IEEE 828-2012:

  1. CM Plan (CMP) обов’язковий — документ описує scope + roles + tools + procedures.
  2. Configuration items (CIs) — identification: criteria for selection (criticality, change probability, complexity, regulatory mandate).
  3. CM activities — мандаторний life-cycle scope: configuration identification (CI naming + numbering + version assignment); configuration control (change request → impact analysis → CCB review → approval/rejection → implementation → verification); configuration status accounting (records of identification + change-request status + as-built configuration); configuration auditing (functional + physical); build management; release engineering.
  4. CM Plan content areas (Annex A) — recommended structure: introduction + management + activities + schedules + resources + plan maintenance.
  5. Roles — CM manager, configuration librarian, CCB (Configuration Control Board), CCB chair, auditors.

IEEE 828-2012 — revision of IEEE 828-2005 (and earlier IEEE 828-1998). Key delta vs 2005: explicitly extended до systems engineering (not only software), added explicit treatment of release engineering and build engineering as first-class concerns (acknowledging modern DevOps + continuous-integration practice де build pipeline це auditable CM artifact). Aligned з ISO/IEC/IEEE 12207:2017 (software life cycle) + ISO/IEC/IEEE 15288:2015 (system life cycle) — обидва standards включають CM як одна з core processes.

Для e-самоката IEEE 828-2012 — operational standard, що задає мінімум:

  • CMP — окремий документ, не just пара punktов у quality manual.
  • Кожна major subsystem (battery pack, controller, display) — окремий CI з власною revision-history.
  • Change-control workflow з CCB approval — кожна BOM зміна, що впливає на form/fit/function або safety, проходить через CCB.
  • Release packaging — кожен firmware-release має SBOM + change-log + signed binaries + traceability до specific test reports (axis EX).

4. SAE EIA-649C:2019 — national consensus standard з 5 CM функціями + 37 принципами

SAE EIA-649C:2019 Configuration Management Standard — опублікований 2019 SAE International (раніше — TechAmerica EIA-649-B:2011, ще раніше — EIA-649-A:2004, original EIA-649:1998). National consensus standard через ANSI — neutral до domain (governmental + industrial + commercial); не імпонує specific terminology або approach; deliberately format-agnostic, щоб one standard міг be applied across DoD, aerospace, medical, automotive, consumer.

5 CM функцій EIA-649C — це backbone усіх інших CM standards (IEEE 828 + ISO 10007 + ISO 26262-8 + DO-178C SCM + ITIL 4 SCM):

  1. Configuration Planning + Management — overall framework (responsibilities + tools + process + integration з QMS).
  2. Configuration Identification — кожен CI має unique identifier + revision + relationship до інших CIs; baselines defined + frozen + maintained.
  3. Configuration Change Management — change-request workflow (ECR → impact analysis → CCB → ECO/ECN → implementation → verification → close-out).
  4. Configuration Status Accounting (CSA) — records: identification + current status + change-request status + as-built configuration + as-maintained configuration; reports on-demand.
  5. Configuration Verification + Audit — FCA (Functional Configuration Audit — verify that actual product performs per requirements) + PCA (Physical Configuration Audit — verify that as-built product matches as-designed documentation).

37 CM principles — distributed across 5 functions; кожен principle deliberately formulated як declarative statement (e.g., principle 6: «Configuration baselines are formally established as a foundation for further work and change control»). Усі 37 принципів можна agregate як CM-program-evaluation checklist; SAE EIA-649C explicitly designed для evaluation criteria, не лише як normative requirements.

EIA-649-1A:2020 — Configuration Management Requirements for Defense Contracts — defense-specific overlay over EIA-649C; референс через DFARS (Defense Federal Acquisition Regulation Supplement); replaced cancelled MIL-STD-973 (cancelled September 2000) і MIL-HDBK-61 (handbook). MIL-STD-3046 Configuration Management — US Army interim standard practice (implements EIA-649C principles plus US Army Acquisition program-specific requirements per DoDI 5000.02).

Для e-самоката EIA-649C принципи прямо застосовні: principle 17 (each CI has a unique identifier — кожна PCB має part-number + revision letter на silkscreen), principle 22 (a configuration change is not implemented until properly approved — кожна BOM-substitution через CCB), principle 26 (records of configuration changes are maintained — change-log персистентний), principle 31 (configuration verification and audit assures that the released configuration matches the actual product — FCA + PCA before each production-batch release).

5. The 5 CM функції — detailed

5.1 Configuration planning + management

Output: Configuration Management Plan (CMP). Mandatory per IEEE 828-2012, recommended per ISO 10007:2017.

Content (per IEEE 828-2012 Annex A):

  • Introduction + scope + purpose + applicable documents
  • CM management — organization + responsibilities + interfaces з QMS + supplier interfaces
  • CM activities — identification + change control + status accounting + audit + build + release
  • Schedules — when each activity occurs у life cycle
  • Resources — tools (PLM/PDM/version control) + personnel + training
  • Plan maintenance — how CMP itself is revision-controlled

5.2 Configuration identification

Output: CI catalog + naming convention + baseline records.

CI (configuration item) — будь-який artifact, що:

  • може бути separately specified, designed, tested, manufactured, configured, released, deployed, maintained
  • має значущість для product safety, quality, regulatory compliance, customer warranty
  • може бути окремо changed

Для e-самоката type CIs:

  • Hardware: frame, fork, battery pack (cell, BMS PCB, enclosure), motor (stator, rotor, magnets), controller PCB (revision letter A/B/C), display PCB, charger, brake-system master cylinder, brake disc, tires (compound revision)
  • Software: BMS firmware (version 1.2.3), ESC firmware, display controller firmware, companion mobile app (iOS + Android — different SBOMs), OTA-update bundle
  • Documents: user manual (revision date), service manual (TSB index), wiring diagrams, BOM (EBOM + MBOM), test reports (V&V evidence per axis EX), DFMEA + PFMEA (axis EN + ET)

Naming convention — unique identifier (e.g., BAT-PCB-001-Rev-C для battery PCB revision C). Version vs revision — version typically applies до software (semver: major.minor.patch), revision typically applies до hardware (letter: A → B → C; minor change might be A.1 → A.2).

Baselines — frozen snapshots:

  • Functional baseline — early-stage; documents функціональні вимоги (what product shall do).
  • Allocated baseline — mid-stage; functional requirements allocated до конкретних subsystems (axis-level decomposition).
  • Developmental baseline — design progresses; intermediate freeze для prototype manufacturing.
  • Product baseline — pre-production freeze; as-designed authoritative reference.
  • As-built baseline — per-unit record; what actually got assembled у конкретний serial-number.
  • As-maintained baseline — current state у field after warranty repairs, OTA updates, recall fixes.

5.3 Configuration change management

Workflow: ECR (Engineering Change Request) → impact analysis → CCB (Configuration Control Board) review → ECO (Engineering Change Order) / ECN (Engineering Change Notice) issuance → implementation → verification → close-out.

Impact analysis — mandatory: every change must be evaluated for impact на:

  • Form / fit / function (FFF) — does change affect interchangeability?
  • Safety (axis EM functional safety) — does change degrade ASIL evidence?
  • Regulatory (axis ED regulatory) — does change re-trigger type approval?
  • Cost
  • Schedule
  • Supplier contracts — sole-source vs alternate-source?
  • Warranty — does change require warranty bulletin?
  • Field action — does change require recall / TSB?

CCB — Configuration Control Board / Change Control Board — cross-functional committee (engineering + manufacturing + quality + service + sales + regulatory) — decides approve / reject / defer / request more info. Decision authority scaled per change class:

  • Class I change — affects form/fit/function/safety/regulatory — full CCB review.
  • Class II change — administrative/clarification — single-engineer approval acceptable.

Deviation + waiver:

  • Deviation request — permission to deviate from approved configuration before production (e.g., supplier delivered batch with one component substituted).
  • Waiver — permission to deliver product that does not fully conform to baseline (e.g., cosmetic defect; functional spec met but visual spec not).
  • Concession — buyer accepts non-conforming product knowing it differs from baseline.

5.4 Configuration status accounting (CSA)

Output: records that enable on-demand answer до queries:

  • What is current released revision of CI X?
  • What is as-built configuration of unit serial number Y?
  • What is as-maintained configuration of unit serial Y after OTA Z?
  • Which units carry CI X revision C? (recall scoping query)
  • Which change requests are open / approved / in-progress / closed?
  • What is rationale behind change request #N?

Tools: PLM (Product Lifecycle Management — Teamcenter / Windchill / ENOVIA / Aras / Oracle Agile) for hardware, version control + artifact registry (Git + GitHub/GitLab + Nexus/Artifactory) for software, CMDB (ITIL 4) for service-installed configuration, ERP (SAP / Oracle / Infor) for BOM + supplier + serial-number link.

5.5 Configuration verification + audit

FCA (Functional Configuration Audit) — verifies that actual product performs per functional requirements + specifications. Mapped до V&V axis EX — V&V evidence is input до FCA.

PCA (Physical Configuration Audit) — verifies that as-built product physically matches as-designed documentation. PCB silkscreen revision letter matches drawings; BOM matches manifest; firmware versions match release-notes; serial-number labels match production records.

Both audits typically conducted before each baseline release. Recurring PCA at sample-rate per shipment batch (manufacturing-quality axis ET cross-link — Cpk discipline на production assembly).

6. DO-178C SCM — Section 7 + Table A-8

RTCA DO-178C / EUROCAE ED-12C Software Considerations in Airborne Systems and Equipment Certification — опублікований December 2011, replaces DO-178B:1992. Companion documents: DO-330 Software Tool Qualification Considerations, DO-331 Model-Based Development and Verification Supplement, DO-332 Object-Oriented Technology and Related Techniques Supplement, DO-333 Formal Methods Supplement. Accepted FAA AC 20-115C + EASA via Certification Memorandum.

Section 7 Software Configuration Management Process + Table A-8 Software Configuration Management Process Objectives — 6 SCM objectives:

#ObjectiveApplicable Level
7-1Configuration items are identifiedA, B, C, D
7-2Baselines and traceability are establishedA, B, C, D
7-3Problem reporting, change control, change review, and configuration status accounting are establishedA, B, C, D
7-4Archive, retrieval, and release are establishedA, B, C, D
7-5Software load control is establishedA, B, C, D
7-6Software life cycle environment control is establishedA, B, C, D

Усі 6 objectives applicable до Levels A (catastrophic — failure prevents continued safe flight) через D (minor — failure has minor effect on aircraft). Level E (no safety effect) — DO-178C не applies. Total objectives across all DO-178C Tables: 71 (Level A: 71; Level B: 69; Level C: 62; Level D: 26; Level E: 0).

SCMP (Software Configuration Management Plan) — primary deliverable Section 7. Companion document до SQAP (per SQA process Section 8) + SDP (Software Development Plan, Section 4). SCAR — Software Configuration Assurance Report (less common term; often subsumed under SQA records).

For e-scooter context: DO-178C не applies safety-critical airborne; але discipline transferable. Modern e-scooter controllers run firmware that affects brake-by-wire / regen-coordination / motor torque-vectoring — за функціональною критичністю approaching ASIL B (cars) / equivalent SIL 2 (IEC 61508). DO-178C SCM rigor — practical model для e-scooter firmware SCM: every binary released має traceable build (compiler version + source revision + dependency versions + build environment hash); archive retention period аналогічна service-life (8-10 years for e-scooter).

7. ISO 26262-8:2018 — automotive functional-safety CM

ISO 26262-8:2018 Road vehicles — Functional safety — Part 8: Supporting processes — опублікований December 2018 як revision 1st edition 2011; sponsored ISO/TC 22/SC 32. Part 8 містить supporting processes infrastructure для решти parts 3-7 (concept + product development при system / hardware / software levels).

Clause 7 — Configuration management — встановлює, що:

  • CMP обов’язковий для items / elements в обсязі ISO 26262
  • Кожен work product має unique identifier дозволяючи storage + retrieval at will
  • Дозволяє reconstruction historical configurations
  • Інтегрується з change management (clause 8) + documentation (clause 10) + verification (clause 9) + tool qualification (clause 11)

Clause 8 — Change management — встановлює:

  • Change request → impact analysis (включно з safety-impact analysis — must assess чи affects safety case / ASIL evidence / safety goals)
  • Approval workflow (CCB equivalent)
  • Implementation + verification + close-out

Clause 9 — Verification — vehicles supporting processes verification activities. Cross-link до V&V axis EX (verification of items vs supporting-process verification differ слегка у focus — clause 9 verifies that supporting processes themselves operate correctly).

Clause 10 — Documentation management — documentation of safety lifecycle artifacts (work products) — mandatory retention + mandatory traceability + mandatory revision control.

Clause 11 — Tool qualification — TCL (Tool Confidence Level) assessment + tool qualification per TCL 1/2/3.

Clause 12 — Qualification of software components + clause 13 — Qualification of hardware components — cross-link до supplier CM (alternate-source qualifications).

For e-scooter context: ISO 26262 не legally mandates для e-scooters (vehicle classification varies — micromobility falls under EN 17128 / UL 2272 / regulatory axis ED, not ISO 26262 automotive scope). But discipline transferable — рекомендована best-practice baseline для high-end e-scooter (1500 W+ motor, autonomous safety features) is ISO 26262 ASIL A/B-equivalent rigor; що means full ISO 26262-8 CM compliance.

8. ITIL 4 service configuration management + CMDB + CMS

ITIL 4 (most recent major release ITIL 4 Foundation 2019 + subsequent editions; current AXELOS/PeopleCert) defines Service Configuration Management як one of 34 ITIL management practices. Successor до ITIL v3 Service Asset and Configuration Management (SACM) (split у ITIL 4 на дві окремі practices: IT Asset Management + Service Configuration Management).

Purpose: ensure that accurate + reliable information about configuration of services + supporting CIs (configuration items) is available when + where needed, including how CIs are configured + relationships between them.

CMDB (Configuration Management Database) — physical store of CI records: hardware + software + networks + buildings + people + supplies + documentation. CMS (Configuration Management System) — set of tools + data ABOVE one or more CMDBs: collecting + storing + managing + updating + analyzing + presenting CI data.

Key differences from V&V CI catalog:

  • ITIL 4 SCM oriented на operational service delivery (e.g., scooter fleet operator running 5 000 units across 3 cities)
  • ISO 10007 / IEEE 828 CM oriented на product lifecycle (e.g., manufacturer maintaining product line)

For e-scooter ecosystem обидві necessary:

  • Manufacturer side — IEEE 828 / EIA-649C CMP, що tracks all units produced + all firmware/BOM revisions
  • Operator / sharing service side — ITIL 4 SCM + CMDB, що tracks current fleet state (which scooter at which location, current firmware version, last maintenance date, current battery degradation state)

Modern ITIL 4 principle: «optimize and automate» — Service Configuration Management practice has be highly automated (auto-discovery + auto-population CMDB). Sharing-fleet IoT telemetry + GPS + diagnostic stream → CMDB feed.

9. CMMI v2.0 — Configuration Management practice area

CMMI v2.0 (Capability Maturity Model Integration version 2.0) — released by CMMI Institute (acquired by ISACA в 2016). Practice area renaming з v1.3 «Process Area» на «Practice Area» — to emphasize CMMI не collection of rote processes а collection of practices to run + manage projects.

Configuration Management practice area в CMMI v2.0 — unique: only 2 capability levels (other practice areas: 3-5 levels). Suggests CM більш binary — або implemented, або не — на відміну від, скажімо, Estimation practice area що scales.

CM purpose: establish + maintain integrity of work products using:

  • Configuration identification
  • Configuration control
  • Configuration status accounting
  • Configuration audits

— тобто 4 of 5 EIA-649C functions (CMMI omits «planning + management» як separate, subsumes у overall project management). CMMI v2.0 CM aligned з ISO 10007:2017 + IEEE 828-2012.

CMMI appraisal — formal benchmark of organization’s process maturity; maturity level 2 (Managed) requires CM practice area implemented; maturity level 3+ (Defined / Quantitatively Managed / Optimizing) vincula CM з cross-practice integration. For e-scooter contract manufacturer (CM = original-design-manufacturer ODM serving brand), CMMI appraisal at ML 2+ — common procurement gate.

10. NIST SP 800-128 — Security-Focused Configuration Management

NIST SP 800-128 Guide for Security-Focused Configuration Management of Information Systems — originally published August 2011; updated October 10, 2019 errata. Supporting NIST framework — provides guidance для federal agencies + contractors implementing SecCM (Security-focused Configuration Management).

Relationship до broader NIST controls:

  • NIST SP 800-53 Security and Privacy Controls — CM control family (CM-1 through CM-12): CM-1 Policy + Procedures; CM-2 Baseline Configuration; CM-3 Configuration Change Control; CM-4 Security Impact Analysis; CM-5 Access Restrictions for Change; CM-6 Configuration Settings; CM-7 Least Functionality; CM-8 Information System Component Inventory; CM-9 Configuration Management Plan; CM-10 Software Usage Restrictions; CM-11 User-Installed Software; CM-12 Information Location.
  • FIPS 200 Minimum Security Requirements — references CM як mandatory minimum.
  • FedRAMP Federal Risk and Authorization Management Program — cloud-service-specific CM controls (FedRAMP Moderate / High baselines include all CM-1 through CM-12).

SecCM activities focus: managing + monitoring configurations to achieve adequate security + minimize organizational risk while supporting business functionality.

For e-scooter: SecCM principles map directly до connected-scooter context (axis cybersecurity = interconnect-trust axis). Companion mobile app + cloud backend + OTA service = «information system» per NIST scope. CM-2 baseline (frozen security configuration) + CM-3 change-control (security-impact-analysis required for every firmware change) + CM-8 component inventory (SBOM) — directly applicable.

11. Software Bill of Materials (SBOM) — NTIA + EO 14028 + EU CRA

SBOM (Software Bill of Materials) — formal, machine-readable inventory of software components used to build a product. Has emerged as critical CM artifact through 2020-2026 regulatory wave:

  • US EO 14028 (Executive Order on Improving the Nation’s Cybersecurity, May 2021) — mandates SBOM provision для federal-software acquisition.
  • NTIA SBOM minimum elements (US Department of Commerce, July 2021) — supplier, component, version, hash, dependency relationship, author, timestamp.
  • EU Cyber Resilience Act (CRA) — entered into force December 2024; Annex I § 1.2.f requires SBOM for products with digital elements (PDE); 36-month enforcement deadline по 11 December 2027.
  • UN R155 + R156 — cybersecurity management system (CSMS) + software update management system (SUMS) for vehicles; R156 § 7.1.1 requires manufacturers maintain software identification mapping (SBOM-equivalent для vehicle software).

SBOM formats (interoperable, machine-readable):

  • CycloneDX — OWASP-led; JSON/XML.
  • SPDX (Software Package Data Exchange) — Linux Foundation; ISO/IEC 5962:2021.
  • SWID tags — ISO/IEC 19770-2:2015.

For e-scooter: SBOM applicable до:

  • BMS firmware (third-party RTOS + battery-management library + cell-model library)
  • ESC firmware (motor-control library + CAN stack + bootloader)
  • Display controller firmware
  • Companion mobile app (OAuth library + analytics SDK + map provider SDK + payment SDK)
  • Cloud backend (database + API framework + ML libraries)

When a CVE drops у third-party RTOS, SBOM enables manufacturer immediately answer: «Which of our scooter models у яких production years carry affected version?» Without SBOM the answer demands manual code audit — too slow for safety-critical updates.

12. Firmware versioning + OTA + Uptane + UN R156

E-scooter typically has 4 firmware-update domains: BMS, ESC (motor controller / VCU), display controller, companion mobile app. Each must be configuration-tracked independently:

  • Naming: semver (major.minor.patch) — major = breaking interface change (BMS protocol upgrade); minor = new feature (regen-curve revision); patch = bugfix (overflow on display temperature readout).
  • Display: firmware version visible на display + у companion app + у service-mode menu.
  • Distribution: OTA (over-the-air) standard; bootloader-only fallback for hardware-revision boundaries.

OTA integrity — must prevent:

  • Tampering: signed firmware (axis cybersecurity ECDSA / RSA-PSS + SHA-256 + chain-of-trust to root key у secure element / OTP fuse).
  • Rollback до vulnerable version: monotonic version counter у secure storage + bootloader rollback-prevention.
  • Mid-update failure: dual-bank / A/B partition + atomic swap + fallback до previous bank.
  • Bricking: integrity check before activation + crash-recovery boot strategy.

Uptane — open-source framework для automotive OTA (joint NYU Tandon + UMTRI + HERE Technologies / Mahindra; 2017+); reference implementation for vehicles. Designed specifically для compromise-resilient OTA — uses multiple offline keys + roles separation (root + targets + timestamp + snapshot).

UN R156 — UNECE WP.29 regulation Software Update Management System (SUMS) — entered into force January 2021 для new vehicle types. Mandates:

  • Manufacturer maintains software identification numbers for each software version + each affected vehicle (SBOM-equivalent).
  • Documented update process — risk assessment per update.
  • Rollback capability — recovery from failed update.
  • Independent vehicle approval — type approval for SUMS process.

Aligned з ISO/SAE 21434:2021 (axis cybersecurity) — every software update can affect threat model + TARA outcomes.

For e-scooter context: R156 не legally applies до micromobility, але discipline transferable. Quality-tier e-scooter manufacturers voluntarily implement R156-equivalent SUMS — це market differentiator + reduces recall risk.

13. BOM revisions + part interchangeability + as-built records

BOM (Bill of Materials) types:

  • EBOM (Engineering BOM) — owned by engineering — reflects design intent; uses engineering identifiers.
  • MBOM (Manufacturing BOM) — owned by manufacturing — reflects production reality; includes assembly-only items (e.g., screws, packaging) + supplier part numbers.
  • SBOM service (≠ Software BOM) — owned by service — reflects parts available для warranty + repair.

BOM revision — incrementing letter (А → B → C; «I» typically skipped to avoid confusion with «1»). Each revision triggered by ECO; impact-analysis tracks affected serial-number range.

Part interchangeability — Form/Fit/Function (FFF):

  • Form — physical envelope identical.
  • Fit — mating interfaces (mechanical + electrical) identical.
  • Function — performance specifications identical (within tolerance).
  • FFF-interchangeable — older revision can be replaced with newer revision у service without redesign. Standard practice — non-FFF changes get new part-number entirely, FFF-compatible changes get revision letter only.

As-built record — per-unit immutable record: serial number → list of installed CI revisions (battery pack S/N + cell lot + BMS firmware version + ESC firmware version + display firmware version + controller PCB revision + …). Stored у MES (Manufacturing Execution System) + transferred до warranty + service systems.

Device History Record (DHR) — terminology from FDA QSR 21 CFR 820.184 (medical devices); analogous concept у automotive (ISO 26262-7:2018 production records). Per-unit record что includes: device identification, manufacture dates, quantity manufactured, equipment used, primary identifications, label copies. Recommended practice для high-quality e-scooter, even though not legally mandated.

PPAP Part Submission Warrant (axis manufacturing-quality ET) cross-link — PPAP Element 18 (design records) + Element 17 (sample production parts) require BOM-revision freeze + as-built sample retention for entire program duration.

14. Serial numbers + lot numbers + recall management + TSB

Serial number — unique identifier per individual unit; typically на frame stamping + label on battery pack + label on motor + label on controller. Lot number — batch identifier per group of components produced together (e.g., 1000 battery cells from same coating line + electrolyte fill batch). Recall scoping depends critically on serial-to-build mapping:

  • «Recall affects units S/N 1A0001-1A4250 carrying battery pack S/N B-2034-* containing cells lot LCL-2024-W34» — useful, actionable.
  • «Recall affects all 2024 units» — overly broad, costly, undermines manufacturer credibility.

Recall regulatory infrastructure:

  • US — NHTSA (National Highway Traffic Safety Administration) Defect Investigation; manufacturer obligation to file Defect Information Report within 5 working days of determining defect; recall registry public via nhtsa.gov.
  • EU — Safety Gate (formerly RAPEX) Rapid Alert System for dangerous non-food products; manufacturer obligation per GPSR (General Product Safety Regulation, EU 2023/988); public via ec.europa.eu/safety-gate.
  • UK — PSD (Product Safety Database) operated by OPSS (Office for Product Safety and Standards).

Recall workflow:

  1. Defect awareness — field reports, warranty claims, regulatory inquiry, self-discovery.
  2. Investigation — RCA (root cause analysis) — identifies CI + revision + lot scope.
  3. Risk assessment — likelihood × severity per axis EV.
  4. Decision — recall vs TSB vs no-action.
  5. Filing — notify regulator (5 working days NHTSA / per GPSR-required timeline).
  6. Customer notification — letters / app push / website.
  7. Remediation — repair / replace / refund.
  8. Status accounting — record per VIN/serial: notified → scheduled → completed → unresponsive.

TSB (Technical Service Bulletin) — non-recall service action; addresses known issue без safety mandate; documented через service-information system; tracked via CSA. Lifecycle: draft → review → release → revision (if updated) → obsolete.

Warranty BOM — list of parts permanently entered into warranty system as approved-for-replacement; each entry FFF-interchangeable with original; covers ECO-triggered substitutions (e.g., revision-C controller PCB approved as warranty replacement for revision-A or revision-B controllers).

15. 33-row cross-axis matrix — CM relevance до 33 prior axes

#AxisCM activity / record
1Battery (BMS)BMS firmware versioning + cell lot traceability + pack S/N → cell lot mapping
2BrakeBrake-pad compound revision + master cylinder vendor lot + hose batch
3Motor + controllerESC firmware versioning + motor stator winding revision + magnet supplier lot
4SuspensionSpring rate revision + damper oil viscosity + bushing compound
5TireCompound revision + carcass construction revision + sidewall rating
6Lighting + visibilityLED bin code + driver-IC revision + reflector tooling revision
7Frame + forkAlloy grade + heat-treat lot + weld map + paint batch
8Display + HMIDisplay firmware version + LCD vendor + touch-controller revision
9Charger SMPSTransformer revision + magnetics vendor + IEC 62368 test report rev
10Connector + wiringCrimp tooling revision + connector vendor + wire gauge + insulation lot
11IP-protectionGasket compound + seal vendor + IPX test report revision
12BearingsBearing vendor + grease lot + ISO 281 L10 report rev
13Stem + foldingLatch revision + spring lot + lock pin batch
14Deck + footboardGrip-tape lot + deck CNC program revision + paint batch
15Handgrip + leverGrip compound + lever assembly revision + throttle vendor
16Wheel + rim + spokeRim alloy lot + spoke gauge + tension report per unit
17Fastener + jointBolt grade + torque-spec revision + adhesive batch
18Thermal managementHeatsink revision + TIM lot + thermal-test report rev
19EMCPre-compliance vs production-unit + emission-report rev
20CybersecurityFirmware signing key version + secure-element OTP fuse map + TARA revision
21NVHVibration-isolator revision + acoustic-test report rev
22Functional safetyASIL evidence freeze + safety case revision + change-impact analysis
23Battery lifecycleRecycling-process revision + cell-chemistry datasheet rev
24RepairabilityService manual revision + spare-part interchangeability matrix
25Environmental robust.Test-spec revision + chamber-test report rev
26PrivacyDPIA revision + data-processor list rev + sub-processor inventory
27RegulatoryType-approval certificate revision + COC (Certificate of Conformity) lot mapping
28Reliability predictionMTBF model revision + FMEDA revision + reliability-allocation rev
29Software + firmwareSource-control snapshot per release + SBOM per release + build-environment hash
30Human factorsErgonomics-test report revision + anthropometric-fit study rev
31Manufacturing qualityPPAP element 18 design records + Cpk per BOM revision + SPC chart per lot
32Risk managementRisk register revision + treatment-plan revision + control-effectiveness audit rev
33V&VTest-plan revision + V&V report freeze per baseline + RTM rev

Pattern observation: кожна prior axis produces artifacts (test reports, design documents, BOM, firmware, certificates) — CM axis specifies how those artifacts are identified, baselined, versioned, audited, retrieved. CM — substrate для всіх інших axes.

16. Owner-level CM «tells» — DIY checklist

Перевіряючи e-самокат як власник, 8 практичних tests показують, чи виробник серйозно ставиться до CM:

  1. Firmware version visibility — у display service-mode + у companion app має бути виставлений номер версії firmware. Sub-test: відкрий app → settings → about → перевір, що показано принаймні 3 окремі versions (BMS, ESC, display). Серйозний viробник — показує всі 3. Cheap brand — показує одну generic «firmware version» або нічого.

  2. Serial-number sticker location + content — окремий serial label має бути на frame (під steerер tube або на bottom of deck), на battery pack, на motor housing. Each label має містити не лише S/N, а й revision letter або BOM revision code. Cheap brand — generic label без revision info.

  3. PCB revision letter on silkscreen — для тих, хто здатний відкрити controller cover: PCB має шовкографію з part number + revision letter (e.g., CTL-Rev-C-2024-Q3). Reputable manufacturer disciplined; counterfeit / no-name — generic «v1» або відсутність позначки.

  4. Recall lookup via VIN/serial — на сайті виробника має бути recall-lookup form або link на NHTSA / EU Safety Gate / UK PSD; sub-test: вписати S/N → отримати recall-status. Cheap brand — recall functionality відсутня; сама не filed recalls в офіційні registries.

  5. Service manual revision date + revision-history page — service manual (or owner’s manual) має revision date + revision-history table (Rev A 2024-01-15 / Rev B 2024-06-10 / …). Без revision history — manual stale; нові TSBs нікуди не intecruется.

  6. Warranty replacement BOM verification — питання service center: «Якщо ти поставляєш мені новий controller через warranty, чи буде це той самий revision letter, що в моєму поточному unit, чи новіший?» Серйозний — каже «це buf revision C, ваш був B; new revision C is FFF-interchangeable з B per ECO #N». Cheap — пусте місце, «just install it».

  7. OTA update change-log discipline — кожен OTA update має published change-log (release notes); change-log містить: version number + release date + scope (BMS / ESC / display) + summary of changes. Cheap brand — silent updates without changelog (a security + safety smell).

  8. Spare-part interchangeability documentation — публічна (PDF on website) або service-center-accessible matrix що mapping which spare-part номери compatible з якими model-years + revision ranges. Серйозний — matrix існує. Cheap brand — «just buy the one with the same part number, hope for compatibility».

Yellow flags: «firmware update» через USB-from-PC procedure без version-history; service center has no record of your unit’s S/N → BOM mapping; OEM unable to identify which production batch your unit came from; no published recall channel.

Green flags: dedicated OTA system with version-history visible в app; service center can quote your unit’s full as-built configuration on first inquiry; published TSB index searchable by S/N range; recall lookup functional with VIN/S/N input.

17. Future axes — куди axis-серія розширюватиметься

CM engineering закриває the configuration-discipline meta-axis — what exactly we have, how we know, how we change it. Наступні axes у серії:

  • Production logistics + supply-chain security ISO 28000:2022 + C-TPAT + AEO — окрема axis для traceability + chain-of-custody через supplier tiers + customs + warehousing + final-mile distribution. ISO 28000:2022 Security and resilience — Security management systems; C-TPAT (Customs-Trade Partnership Against Terrorism, US CBP); AEO (Authorized Economic Operator, EU + WTO).

  • Project management ISO 21500:2021 + ISO 21502:2020 + PMBOK + PRINCE2 — окрема axis для structured project execution (scope + schedule + cost + quality + risk + stakeholder management). Cross-link до axes EQ (reliability program management) + EV (risk management) + EX (V&V) + EZ (CM) — project management — meta-orchestrator.

  • Sustainability + circular-economy ISO 14001 + ISO 14040 LCA + ISO 14067 carbon footprint + EU Green Deal + Right to Repair — окрема axis для product carbon footprint + LCA + circular-design + EOL management. Cross-link до axis EE (battery lifecycle recycling) + axis EF (repairability) — sustainability — broader umbrella.

  • Acquisition + procurement ISO/IEC/IEEE 15288 acquisition + ISO 31000 supplier-risk + counterfeit-parts mitigation per AS5553 + IDEA-STD-1010 — supply-chain procurement discipline.

  • Knowledge management ISO 30401:2018 + ISO 9001 organizational knowledge clause 7.1.6 — discipline збереження + transfer organizational knowledge across lifecycle phases + personnel transitions.

Кожна future axis буде окремою content-cycle deep-dive у тому ж 17-section pattern.

Підсумок — CM concept-як-pattern

Configuration management engineering — це сьома process meta-axis (паралельна до reliability-prediction EN + SW-process EP + human-machine-fit ER + manufacturing-process ET + risk-anticipation EV + verification-validation EX). Її unique роль — substrate, що prив’язує усі artifacts усіх інших 33 axes до конкретних identifiable + versionable + traceable + auditable records.

Trinity (ISO 10007 + IEEE 828 + EIA-649C) надає the standardized vocabulary, process structure, і evaluation criteria. Domain-specific standards (DO-178C SCM + ISO 26262-8 + NIST SP 800-128) overlay extra rigor for high-assurance contexts. Operational frameworks (ITIL 4 SCM + CMMI v2.0 CM) translate the principles into runnable practice. Modern artifacts (SBOM + OTA + UN R156 + SUMS) extend CM до digitally-connected reality of contemporary e-mobility.

Без CM specifications reliability MTBF (axis EN), risk-treatment effectiveness (axis EV), V&V evidence (axis EX), manufacturing Cpk (axis ET), і regulatory type approval (axis ED) не прив’язуються до конкретного physical unit у руках конкретного user’а. CM робить усі попередні 33 axes operationally meaningful.

ENG-first джерела (0 російських, 30+ official):

  • ISO 10007:2017 Quality management — Guidelines for configuration management — iso.org/standard/70400
  • IEEE 828-2012 Standard for Configuration Management in Systems and Software Engineering — standards.ieee.org/standard/828-2012
  • SAE EIA-649C:2019 Configuration Management Standard — webstore.ansi.org/standards/sae/saeeia649c2019
  • SAE EIA-649-1A:2020 Configuration Management Requirements for Defense Contracts
  • ISO/IEC/IEEE 24765:2017 Systems and software engineering — Vocabulary
  • ISO/IEC/IEEE 12207:2017 Software life cycle processes
  • ISO/IEC/IEEE 15288:2015 System life cycle processes
  • ISO 9001:2015 clause 8.5.2 Identification and traceability
  • IATF 16949:2016 clause 8.5.2 (automotive QMS overlay)
  • RTCA DO-178C / EUROCAE ED-12C Software Considerations in Airborne Systems and Equipment Certification Section 7 + Table A-8
  • ISO 26262-8:2018 Road vehicles — Functional safety — Part 8: Supporting processes clauses 7-11
  • ITIL 4 Service Configuration Management practice — AXELOS/PeopleCert
  • CMMI v2.0 Configuration Management practice area — CMMI Institute / ISACA
  • NIST SP 800-128 Guide for Security-Focused Configuration Management of Information Systems — csrc.nist.gov/pubs/sp/800/128/upd1/final
  • NIST SP 800-53 Rev. 5 CM control family (CM-1 through CM-12)
  • FIPS 200 Minimum Security Requirements
  • US EO 14028 Improving the Nation’s Cybersecurity (May 2021) SBOM mandate
  • NTIA Minimum Elements for a Software Bill of Materials (SBOM) (July 2021)
  • EU Cyber Resilience Act (CRA) Annex I § 1.2.f SBOM requirement
  • UN ECE R155 Cybersecurity Management System (CSMS) + R156 Software Update Management System (SUMS)
  • ISO/SAE 21434:2021 cross-link
  • ISO/IEC 5962:2021 SPDX Specification
  • ISO/IEC 19770-2:2015 SWID tags
  • CycloneDX SBOM specification (OWASP)
  • Uptane Standard for Design — uptane.github.io
  • MIL-STD-973 (cancelled 2000) historical reference
  • MIL-STD-3046 US Army interim CM standard
  • FDA QSR 21 CFR 820.184 Device History Record — analogous discipline
  • AIAG PPAP 4th edition + AIAG-VDA PPAP — Element 17 + Element 18
  • NHTSA Defect Investigation + recall registry nhtsa.gov/recalls
  • EU Safety Gate (formerly RAPEX) ec.europa.eu/safety-gate-alerts
  • UK Product Safety Database (PSD) operated by OPSS