E-scooter Configuration Management engineering as the 34th 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 min read

In the engineering-guide series we covered the battery with BMS and thermal-runaway intro, the brake system, motor and controller, suspension, tires, lighting and visibility, frame and fork, display + HMI, SMPS CC/CV charger, connector + wiring harness, IP protection, bearings with ISO 281 L10, stem and folding mechanism, the deck, handgrip + lever + throttle, the wheel as an assembly, fastener engineering as the joining-axis, thermal management as the heat-dissipation axis, EMC/EMI as the interference-mitigation axis, cybersecurity as the interconnect-trust axis, NVH as the acoustic-vibration-emission axis, functional safety as the safety-integrity axis, battery-lifecycle engineering as the sustainability axis, reparability as the repairability axis, environmental robustness as the environmental-conditioning axis, privacy and personal-data protection as the privacy-preservation axis, reliability engineering as the reliability-prediction meta-axis, software & firmware engineering as the SW-process axis, human factors and ergonomics as the human-machine fit axis, manufacturing-quality engineering as the manufacturing-process axis, risk-management engineering as the risk-anticipation meta-axis and V&V engineering as the verification-validation meta-axis. These 33 engineering axes covered subsystems, joining methods, thermal and electromagnetic phenomena, safety, sustainability, repairability, environmental conditioning, privacy, reliability prediction, SW-process, human-machine fit, manufacturing process, risk anticipation and verification + validation. Verification (EX) tells us whether the product was built right. But that leaves a separate question: what exactly is the product in our hands — bit-exact specifically — and how do we know that in a year, in five years, after the third OTA, after the controller has been resoldered? None of the 33 prior axes addresses this question directly.

Configuration management (CM) engineering is the configuration-discipline meta-axis of the entire e-scooter. It supplies a guideline-level meta-standard (ISO 10007:2017 Quality management — Guidelines for configuration management — non-prescriptive guidance above all other CM standards, aligned with ISO 9001:2015 clause 8.5.2 on identification and traceability), a systems-and-software engineering CM standard (IEEE 828-2012 Standard for Configuration Management in Systems and Software Engineering — minimum requirements for CM processes, CM Plan structure, life-cycle integration), a national consensus standard (SAE EIA-649C:2019 Configuration Management Standard — 5 CM functions + 37 principles, neutral across governmental + industrial + commercial use; 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 with 6 SCM objectives applicable to software levels 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), an IT-service framework (ITIL 4 Service Configuration Management practice + CMDB Configuration Management Database + CMS Configuration Management System), a process-maturity model (CMMI v2.0 Configuration Management practice area with 2 capability levels), and a 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).

This is the thirty-fourth engineering-axis deep-dive in the guide series — and the seventh process meta-axis (parallel to reliability-prediction EN + SW-process EP + human-machine-fit ER + manufacturing-process ET + risk-anticipation EV + verification-validation EX, now configuration-discipline EZ). Like all six prior process meta-axes, the CM axis has no “iron” implementation — it is a discipline that defines how to systematically know what is installed, prove it after the fact, and change it under control. Without CM the BOM revision, firmware version (BMS + ESC + display + app), serial-to-build mapping, recall scope (which units actually carry the defective component), warranty BOM (which spare parts are interchangeable), and even OTA-rollback integrity remain paper claims — not traceable engineering records.

1. CM ≠ V&V ≠ change request: a separate axis

V&V (axis EX) answers “Are we building the product right + the right product?” That is a methodology that proves conformance + fitness. Change request / ECR / ECO (engineering change request / engineering change order) is a tool, not a methodology. CM engineering supplies a separate discipline that answers four principal questions that none of the above closes:

  1. Identification — “What do we have here? How have we named every separate part (CI — Configuration Item) so it can be referenced unambiguously 10 years after disposal? Which baselines have we frozen — functional, allocated, product?”
  2. Change control — “Who approved what change, when, with what rationale, with what impact analysis, and what consequences follow for every affected baseline, supplier contract, certification, warranty?”
  3. Status accounting — “What is the status of each CI right now — released, work-in-progress, obsoleted, recalled? What is the latest approved revision? What still has to happen for this baseline to close?”
  4. Verification + audit — “Does the real physical + digital product match the documentation? FCA — Functional Configuration Audit; PCA — Physical Configuration Audit.”
DimensionV&V engineering (EX)Risk management (EV)Configuration management (EZ)
TriggerStage gate / acceptanceStrategic decision / project initiationContinuous lifecycle — every change
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: one can have full V&V + 0% CM — tests pass for the prototype, but the serial-number-to-build mapping does not exist, so when six months later 1 of 10 000 units in the field starts to evidently overheat, it is impossible to establish whether that specific unit had the same BMS firmware version + the same cell-supplier batch as the prototype that passed V&V. Without CM neither reliability prediction (axis EN), nor risk treatment (axis EV), nor V&V evidence (axis EX) is bound to the specific physical unit in the specific user’s hands. CM is the substrate that makes all prior axes operationally meaningful.

2. ISO 10007:2017 — guideline foundation

ISO 10007:2017 Quality management — Guidelines for configuration management was published in March 2017 as the 3rd edition (preceded by 1995 and 2003); prepared by ISO/TC 176 Quality management and quality assurance, Subcommittee SC 2 Quality systems (the same working group as ISO 9001:2015, the ISO 9000:2015 vocabulary, and ISO 9004:2018). It is a guidance standard (not certifiable, not a requirements standard) — the recommended reference for organisations wishing to integrate CM into an ISO 9001-compatible QMS.

ISO 10007:2017 is non-prescriptive: it does not require specific tools, does not dictate a specific approach, does not impose mandatory templates. Instead it provides guidance on:

  1. Responsibilities — recommended distribution of responsibilities between management, project, supplier, configuration manager, change control board (CCB), configuration auditor.
  2. Configuration-management process — describes 5 key activities (planning + identification + change control + status accounting + audit) aligned with SAE EIA-649C’s 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 — recommends that baselines be documented + frozen + change-controlled.
  6. Change control + change request — recommended workflow.
  7. Status accounting — recommended records.
  8. Audit — recommended types (functional, physical).

ISO 10007:2017 is the default starting point for organisations that do not yet have a CM system. For organisations in regulated domains (aerospace DO-178C, automotive ISO 26262, medical FDA QSR) ISO 10007:2017 serves as complementary — the domain-specific standard dictates what, ISO 10007:2017 supplies the how (recommended structure + workflow). It does not replace EIA-649C for defense contracts, IEEE 828 for systems/software engineering, or ISO 26262-8 for automotive safety. Aligned with ISO 9001:2015 clause 8.5.2 (identification and traceability) — ISO 9001 requires identification + traceability, ISO 10007 explains how to do it.

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

IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering was published 16 March 2012, sponsored by the IEEE Computer Society Software & Systems Engineering Standards Committee (S2ESC). It is a requirements standard (unlike the guidance ISO 10007) — it establishes minimum requirements for CM processes for any form, class, or type of software or system.

Key requirements of IEEE 828-2012:

  1. CM Plan (CMP) is mandatory — a document describing scope + roles + tools + procedures.
  2. Configuration items (CIs) — identification: criteria for selection (criticality, change probability, complexity, regulatory mandate).
  3. CM activities — mandatory 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 is a revision of IEEE 828-2005 (and earlier IEEE 828-1998). Key delta vs 2005: explicitly extended to systems engineering (not only software), added explicit treatment of release engineering and build engineering as first-class concerns (acknowledging modern DevOps + continuous-integration practice where the build pipeline itself is an auditable CM artifact). Aligned with ISO/IEC/IEEE 12207:2017 (software life cycle) + ISO/IEC/IEEE 15288:2015 (system life cycle) — both standards include CM as one of their core processes.

For an e-scooter, IEEE 828-2012 is an operational standard that sets the minimum:

  • The CMP is a separate document, not just a few bullets in the quality manual.
  • Each major subsystem (battery pack, controller, display) is a separate CI with its own revision history.
  • A change-control workflow with CCB approval — every BOM change that affects form/fit/function or safety passes through the CCB.
  • Release packaging — every firmware release carries an SBOM + change-log + signed binaries + traceability to specific test reports (axis EX).

4. SAE EIA-649C:2019 — national consensus standard with 5 CM functions + 37 principles

SAE EIA-649C:2019 Configuration Management Standard was published in 2019 by SAE International (preceded by TechAmerica EIA-649-B:2011, earlier EIA-649-A:2004, original EIA-649:1998). It is a national consensus standard through ANSI — neutral to domain (governmental + industrial + commercial); it does not impose specific terminology or approach; deliberately format-agnostic so that one standard can be applied across DoD, aerospace, medical, automotive, consumer.

EIA-649C’s 5 CM functions form the backbone of every other CM standard (IEEE 828 + ISO 10007 + ISO 26262-8 + DO-178C SCM + ITIL 4 SCM):

  1. Configuration Planning + Management — overall framework (responsibilities + tools + process + integration with the QMS).
  2. Configuration Identification — every CI has a unique identifier + revision + relationship to other CIs; baselines are 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 the actual product performs per requirements) + PCA (Physical Configuration Audit — verify that the as-built product matches the as-designed documentation).

37 CM principles are distributed across the 5 functions; each principle is deliberately phrased as a declarative statement (e.g., principle 6: “Configuration baselines are formally established as a foundation for further work and change control”). All 37 principles can be aggregated into a CM-program-evaluation checklist; SAE EIA-649C is explicitly designed as evaluation criteria, not only as normative requirements.

EIA-649-1A:2020 — Configuration Management Requirements for Defense Contracts — is a defense-specific overlay over EIA-649C; referenced through DFARS (Defense Federal Acquisition Regulation Supplement); replaced the cancelled MIL-STD-973 (cancelled September 2000) and MIL-HDBK-61 (handbook). MIL-STD-3046 Configuration Management is a US Army interim standard practice (implementing EIA-649C principles plus US Army Acquisition program-specific requirements per DoDI 5000.02).

For an e-scooter, EIA-649C’s principles apply directly: principle 17 (each CI has a unique identifier — every PCB carries a part-number + revision letter on its silkscreen), principle 22 (a configuration change is not implemented until it has been properly approved — every BOM substitution passes through a CCB), principle 26 (records of configuration changes are maintained — change-log is persistent), principle 31 (configuration verification and audit assure that the released configuration matches the actual product — FCA + PCA before every production-batch release).

5. The 5 CM functions — 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 — organisation + responsibilities + interfaces with the QMS + supplier interfaces
  • CM activities — identification + change control + status accounting + audit + build + release
  • Schedules — when each activity occurs in the life cycle
  • Resources — tools (PLM/PDM/version control) + personnel + training
  • Plan maintenance — how the CMP itself is revision-controlled

5.2 Configuration identification

Output: CI catalog + naming convention + baseline records.

A CI (configuration item) is any artifact that:

  • can be separately specified, designed, tested, manufactured, configured, released, deployed, maintained
  • has significance for product safety, quality, regulatory compliance, customer warranty
  • can be separately changed

E-scooter CI types:

  • 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 for battery PCB revision C). Version vs revision — version typically applies to software (semver: major.minor.patch), revision typically applies to hardware (letter: A → B → C; a minor change might be A.1 → A.2).

Baselines — frozen snapshots:

  • Functional baseline — early-stage; documents the functional requirements (what the product shall do).
  • Allocated baseline — mid-stage; functional requirements are allocated to specific subsystems (axis-level decomposition).
  • Developmental baseline — design progresses; an intermediate freeze for prototype manufacturing.
  • Product baseline — pre-production freeze; the as-designed authoritative reference.
  • As-built baseline — per-unit record; what actually got assembled for a specific serial number.
  • As-maintained baseline — current state in the 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 on:

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

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

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

Deviation + waiver:

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

5.4 Configuration status accounting (CSA)

Output: records that enable on-demand answers to queries:

  • What is the current released revision of CI X?
  • What is the as-built configuration of unit serial number Y?
  • What is the 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 the 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 the actual product performs per its functional requirements + specifications. Mapped to V&V axis EX — V&V evidence is an input to the FCA.

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

Both audits are typically conducted before every baseline release. Recurring PCA at a sample rate per shipment batch (manufacturing-quality axis ET cross-link — Cpk discipline on the production line).

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

RTCA DO-178C / EUROCAE ED-12C Software Considerations in Airborne Systems and Equipment Certification was published in December 2011 and 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 by 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

All 6 objectives apply to Levels A (catastrophic — failure prevents continued safe flight) through D (minor — failure has minor effect on aircraft). Level E (no safety effect) — DO-178C does not apply. 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) is the primary deliverable of Section 7. Companion document to the SQAP (per SQA process Section 8) + the SDP (Software Development Plan, Section 4). SCAR — Software Configuration Assurance Report (a less common term; often subsumed under SQA records).

For e-scooter context: DO-178C does not apply to safety-critical airborne software here; but the discipline is transferable. Modern e-scooter controllers run firmware that affects brake-by-wire / regen coordination / motor torque vectoring — in functional criticality approaching ASIL B (cars) / equivalent SIL 2 (IEC 61508). DO-178C SCM rigor is a practical model for e-scooter firmware SCM: every binary released has a traceable build (compiler version + source revision + dependency versions + build-environment hash); the archive retention period mirrors service life (8-10 years for an e-scooter).

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

ISO 26262-8:2018 Road vehicles — Functional safety — Part 8: Supporting processes was published in December 2018 as a revision of the 1st edition 2011; sponsored by ISO/TC 22/SC 32. Part 8 contains supporting-processes infrastructure for the remaining parts 3-7 (concept + product development at system / hardware / software levels).

Clause 7 — Configuration management — establishes that:

  • A CMP is mandatory for items / elements in the ISO 26262 scope
  • Every work product has a unique identifier allowing storage + retrieval at will
  • It enables reconstruction of historical configurations
  • It integrates with change management (clause 8) + documentation (clause 10) + verification (clause 9) + tool qualification (clause 11)

Clause 8 — Change management — establishes:

  • Change request → impact analysis (including safety-impact analysis — must assess whether it affects the safety case / ASIL evidence / safety goals)
  • Approval workflow (CCB equivalent)
  • Implementation + verification + close-out

Clause 9 — Verification — supporting-processes verification activities for the vehicle. Cross-link to V&V axis EX (item verification vs supporting-process verification differ slightly in 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 to supplier CM (alternate-source qualifications).

For e-scooter context: ISO 26262 does not legally mandate e-scooters (vehicle classification varies — micromobility falls under EN 17128 / UL 2272 / regulatory axis ED, not ISO 26262 automotive scope). But the discipline is transferable — the recommended best-practice baseline for a high-end e-scooter (1500 W+ motor, autonomous safety features) is ISO 26262 ASIL A/B-equivalent rigor, which 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 as one of 34 ITIL management practices. Successor to ITIL v3 Service Asset and Configuration Management (SACM) (split in ITIL 4 into two separate practices: IT Asset Management + Service Configuration Management).

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

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

Key differences from a V&V CI catalog:

  • ITIL 4 SCM is oriented toward operational service delivery (e.g., a scooter-fleet operator running 5 000 units across 3 cities)
  • ISO 10007 / IEEE 828 CM is oriented toward product life cycle (e.g., a manufacturer maintaining a product line)

For the e-scooter ecosystem both are necessary:

  • Manufacturer side — an IEEE 828 / EIA-649C CMP that tracks every unit produced + every firmware/BOM revision
  • Operator / sharing-service side — ITIL 4 SCM + CMDB that tracks the current fleet state (which scooter at which location, current firmware version, last maintenance date, current battery-degradation state)

Modern ITIL 4 principle: “optimise and automate” — the Service Configuration Management practice has to be highly automated (auto-discovery + auto-population of the CMDB). Sharing-fleet IoT telemetry + GPS + diagnostic streams → CMDB feed.

9. CMMI v2.0 — Configuration Management practice area

CMMI v2.0 (Capability Maturity Model Integration version 2.0) was released by the CMMI Institute (acquired by ISACA in 2016). The practice-area renaming from v1.3 “Process Area” to “Practice Area” emphasises that CMMI is not a collection of rote processes but a collection of practices to run + manage projects.

The Configuration Management practice area in CMMI v2.0 is unique: it has only 2 capability levels (other practice areas have 3-5 levels). This suggests CM is more binary — it is either implemented or not — unlike, say, the Estimation practice area which scales.

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

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

— i.e., 4 of the 5 EIA-649C functions (CMMI omits “planning + management” as a separate practice, subsuming it under overall project management). CMMI v2.0 CM is aligned with ISO 10007:2017 + IEEE 828-2012.

CMMI appraisal is a formal benchmark of an organisation’s process maturity; maturity level 2 (Managed) requires the CM practice area to be implemented; maturity level 3+ (Defined / Quantitatively Managed / Optimizing) binds CM with cross-practice integration. For an e-scooter contract manufacturer (CM = original-design-manufacturer ODM serving a brand), a CMMI appraisal at ML 2+ is a 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 was originally published in August 2011 and received an errata update on October 10, 2019. Supporting the broader NIST framework — it provides guidance for federal agencies + contractors implementing SecCM (Security-focused Configuration Management).

Relationship to 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 as a 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 + minimise organisational risk while supporting business functionality.

For an e-scooter: SecCM principles map directly onto the connected-scooter context (axis cybersecurity = interconnect-trust axis). The companion mobile app + cloud backend + OTA service = an “information system” per the 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) — all directly applicable.

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

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

  • US EO 14028 (Executive Order on Improving the Nation’s Cybersecurity, May 2021) — mandates SBOM provision for 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 an SBOM for products with digital elements (PDE); the 36-month enforcement deadline lands on 11 December 2027.
  • UN R155 + R156 — cybersecurity management system (CSMS) + software update management system (SUMS) for vehicles; R156 § 7.1.1 requires manufacturers to maintain a software-identification mapping (an SBOM equivalent for 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 an e-scooter an SBOM applies to:

  • 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 in a third-party RTOS, an SBOM lets the manufacturer immediately answer: “Which of our scooter models in which production years carry the affected version?” Without an SBOM the answer demands a manual code audit — too slow for safety-critical updates.

12. Firmware versioning + OTA + Uptane + UN R156

An 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 = bug fix (overflow on the display temperature readout).
  • Display: the firmware version is visible on the display + in the companion app + in the service-mode menu.
  • Distribution: OTA (over-the-air) is 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 a root key in a secure element / OTP fuse).
  • Rollback to a vulnerable version: a monotonic version counter in secure storage + bootloader rollback prevention.
  • Mid-update failure: dual-bank / A/B partition + atomic swap + fallback to the previous bank.
  • Bricking: integrity check before activation + a crash-recovery boot strategy.

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

UN R156 is the UNECE WP.29 regulation Software Update Management System (SUMS) — entered into force in January 2021 for new vehicle types. It mandates:

  • The manufacturer maintains software identification numbers for every software version + every affected vehicle (an SBOM equivalent).
  • A documented update process — risk assessment per update.
  • Rollback capability — recovery from a failed update.
  • Independent vehicle approval — type approval for the SUMS process.

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

For e-scooter context: R156 does not legally apply to micromobility, but the discipline is transferable. Quality-tier e-scooter manufacturers voluntarily implement an R156-equivalent SUMS — it is a 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 for warranty + repair.

BOM revision — incrementing letter (A → B → C; “I” is typically skipped to avoid confusion with “1”). Each revision is triggered by an ECO; impact analysis tracks the 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 — the older revision can be replaced with the newer revision in service without a redesign. Standard practice: non-FFF changes get a new part-number entirely; FFF-compatible changes get a 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 in the MES (Manufacturing Execution System) + transferred to warranty + service systems.

Device History Record (DHR) — terminology from FDA QSR 21 CFR 820.184 (medical devices); an analogous concept exists in automotive (ISO 26262-7:2018 production records). A per-unit record that includes: device identification, manufacturing dates, quantity manufactured, equipment used, primary identifications, label copies. Recommended practice for a 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 the entire program duration.

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

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

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

Recall regulatory infrastructure:

  • US — NHTSA (National Highway Traffic Safety Administration) Defect Investigation; manufacturer obligation to file a Defect Information Report within 5 working days of determining a 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 the CI + revision + lot scope.
  3. Risk assessment — likelihood × severity per axis EV.
  4. Decision — recall vs TSB vs no-action.
  5. Filing — notify the regulator (5 working days for NHTSA / per the 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) — a non-recall service action; addresses a known issue without a safety mandate; documented through the service-information system; tracked via CSA. Lifecycle: draft → review → release → revision (if updated) → obsolete.

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

15. 33-row cross-axis matrix — CM relevance to 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: every prior axis produces artifacts (test reports, design documents, BOM, firmware, certificates) — the CM axis specifies how those artifacts are identified, baselined, versioned, audited, retrieved. CM is the substrate for every other axis.

16. Owner-level CM “tells” — DIY checklist

Checking an e-scooter as an owner, 8 practical tests show whether the manufacturer takes CM seriously:

  1. Firmware version visibility — the display service-mode + the companion app should expose firmware version numbers. Sub-test: open the app → settings → about → confirm that at least 3 separate versions are shown (BMS, ESC, display). A serious manufacturer shows all 3. A cheap brand shows one generic “firmware version” or nothing.

  2. Serial-number sticker location + content — separate serial labels should sit on the frame (under the steerer tube or on the bottom of the deck), on the battery pack, on the motor housing. Each label should carry not only the S/N but a revision letter or BOM revision code. A cheap brand uses a generic label with no revision info.

  3. PCB revision letter on the silkscreen — for those willing to open the controller cover: the PCB should carry a silkscreen with part number + revision letter (e.g., CTL-Rev-C-2024-Q3). A reputable manufacturer is disciplined; a counterfeit / no-name uses a generic “v1” or omits the marking entirely.

  4. Recall lookup via VIN/serial — the manufacturer’s website should host a recall-lookup form or link to NHTSA / EU Safety Gate / UK PSD; sub-test: enter the S/N → get the recall status. A cheap brand has no recall functionality and has filed no recalls into official registries.

  5. Service-manual revision date + revision-history page — the service manual (or owner’s manual) should carry a revision date + revision-history table (Rev A 2024-01-15 / Rev B 2024-06-10 / …). Without a revision history, the manual is stale; new TSBs are not being integrated.

  6. Warranty replacement BOM verification — ask the service centre: “If you supply me a new controller under warranty, will it be the same revision letter as in my current unit, or newer?” A serious centre answers “this is revision C; yours was B; the new revision C is FFF-interchangeable with B per ECO #N”. A cheap centre answers with empty air, “just install it”.

  7. OTA update change-log discipline — every OTA update should publish a change-log (release notes); the change-log should contain: version number + release date + scope (BMS / ESC / display) + summary of changes. A cheap brand pushes silent updates without a changelog (a security + safety smell).

  8. Spare-part interchangeability documentation — either public (PDF on the website) or service-centre-accessible matrix mapping which spare-part numbers are compatible with which model years + revision ranges. A serious manufacturer publishes the matrix. A cheap brand says “just buy the one with the same part number, hope for compatibility”.

Yellow flags: “firmware update” via USB-from-PC procedure without version history; the service centre has no record of your unit’s S/N → BOM mapping; the OEM cannot identify which production batch your unit came from; no published recall channel.

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

17. Future axes — where the axis series will grow

CM engineering closes the configuration-discipline meta-axis — what exactly we have, how we know, how we change it. Next axes in the series:

  • Production logistics + supply-chain security ISO 28000:2022 + C-TPAT + AEO — a separate axis for traceability + chain-of-custody across 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 — a separate axis for structured project execution (scope + schedule + cost + quality + risk + stakeholder management). Cross-link to 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 — a separate axis for product carbon footprint + LCA + circular design + EOL management. Cross-link to 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 organisational knowledge clause 7.1.6 — the discipline of preserving + transferring organisational knowledge across lifecycle phases + personnel transitions.

Each future axis will be a separate content-cycle deep-dive in the same 17-section pattern.

Summary — CM concept-as-pattern

Configuration management engineering is the seventh process meta-axis (parallel to reliability-prediction EN + SW-process EP + human-machine-fit ER + manufacturing-process ET + risk-anticipation EV + verification-validation EX). Its unique role is the substrate that binds every artifact of every other 33 axes to specific identifiable + versionable + traceable + auditable records.

The trinity (ISO 10007 + IEEE 828 + EIA-649C) supplies the standardised vocabulary, process structure, and 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 into the digitally-connected reality of contemporary e-mobility.

Without CM the reliability MTBF (axis EN), the risk-treatment effectiveness (axis EV), the V&V evidence (axis EX), the manufacturing Cpk (axis ET), and the regulatory type approval (axis ED) are not bound to the specific physical unit in the specific user’s hands. CM makes all 33 prior axes operationally meaningful.

Sources (ENG-first, 0 Russian, 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