Software-defined vehicles, OTA, and supplier-system modernization for automotive OEMs and suppliers.

Software-defined-vehicle platform work is the architectural and operating-model discipline that determines whether a vehicle program can release software at a cadence the supplier base can support, or whether each release becomes a six-month integration event. The work begins with a current-state E/E architecture assessment, an AUTOSAR Adaptive and Classic split decision, and an honest evaluation of the platform-team operating model against the cadence the program is targeting. A senior consultant produces a domain-controller decomposition aligned to the vehicle's functional domains, an AUTOSAR integration design that defines the supplier-OEM responsibility split clearly, a software-platform release model that synchronizes domain-controller releases with vehicle integration events, and an ASPICE-aligned engineering process that survives a customer audit. Deliverables include the platform architecture decision record, the supplier-collaboration operating model, the release-cadence design, and a roadmap for moving from the current per-program platform to a reusable vehicle-software platform. Successful outcomes look like a vehicle program that delivers a software release inside its planned window without a tier-1 escalation, an over-the-air update path that the platform supports natively rather than as an add-on, and a supplier base that aligns to the OEM's cadence rather than constraining it. An engagement typically runs twelve to twenty weeks, embedded with the chief software officer's organization, vehicle-program engineering, and the tier-1 platform suppliers.

Over-the-air update infrastructure under UNECE WP.29 R156 is the program-and-platform discipline of treating each software update as a controllable operation with rollback, telemetry, and regulatory evidence, rather than a deployment hope. The work begins with a current-state OTA capability assessment, an R156 software-update-management-system gap analysis, and a fleet-telemetry inventory that determines what the OEM can actually observe post-deployment. A senior consultant produces an SUMS process design aligned to R156 requirements, a campaign-management architecture that supports staged rollouts with defined rollback criteria, a telemetry-and-observability design that catches a bad campaign before it propagates beyond a containable cohort, and a cybersecurity-management-system integration aligned to R155 and ISO/SAE 21434. Deliverables include the SUMS process documentation that the type-approval authority will accept, the campaign-architecture decision record, the rollback-and-recovery runbooks, and a fleet-telemetry roadmap that supports both safety and customer-experience use cases. Successful outcomes look like a campaign that staged-rolls cleanly with measurable error-rate gating between cohorts, a rollback exercise actually tested rather than documented, and a type-approval review that closes without R156 findings. An engagement typically runs ten to sixteen weeks, embedded with vehicle cybersecurity, the connected-vehicle platform team, regulatory affairs, and the cloud platform engineering function.

ADAS and AV data-pipeline work is the architectural discipline that produces a safety case the regulator will read two years after the build. The work begins with a current-state data-pipeline assessment from fleet ingest through labelling to scenario libraries, an ISO 21448 SOTIF and ISO 26262 functional-safety alignment review, and a reproducibility audit that determines whether a model trained eighteen months ago can be re-derived from source data on demand. A senior consultant produces a fleet-ingest architecture with privacy-preserving data handling appropriate to General Data Protection Regulation (GDPR) and emerging US state-level vehicle-data statutes, a labelling-pipeline operating model with quality-assurance and inter-rater-reliability discipline, a scenario-library architecture that supports both replay and synthetic generation, and an experiment-tracking system that captures the lineage from raw clip to deployed model. Deliverables include the data-pipeline architecture decision record, the labelling operating model, the scenario-library design, and a safety-case-evidence framework that ties pipeline artifacts to the assertions the safety case makes. Successful outcomes look like a regulator query about a model decision in a three-year-old build that the OEM can answer with reproduced data and reproduced training, a labelling cycle time materially reduced through process discipline rather than vendor change, and a safety-case package that survives a type-approval or NHTSA review. An engagement typically runs twelve to twenty weeks, embedded with the AV/ADAS engineering organization, functional safety, the data-platform team, and regulatory affairs.

Dealer-system modernization is the change-management discipline that determines whether a DMS replatforming or dealer-portal rebuild lands across a fragmented dealer network or stalls at the second pilot. The work begins with a dealer-network segmentation by size, ownership structure, and current-platform footprint, a current-state DMS-and-portal capability assessment, and a stakeholder map that includes the OEM's field-operations team, the dealer-council leadership, and the major dealer-group IT functions. A senior consultant produces a deployment-strategy decision record that handles the heterogeneity of the dealer base, a dealer-portal architecture aligned to the OEM's customer-data and lead-management strategy, a DMS-integration design that survives the variations across the major DMS providers, and a change-management plan grounded in actual dealer adoption discipline rather than OEM-side assumptions. Deliverables include the deployment-strategy decision record, the portal-architecture decision record, the DMS-integration patterns, and a dealer-engagement playbook for the field-operations team. Successful outcomes look like a dealer-portal launch that the dealer council accepts, a DMS-integration backlog that converges rather than expanding, and a customer experience consistent across the dealer network in the digital handoffs that the OEM controls. An engagement typically runs ten to sixteen weeks, embedded with the OEM's field-operations team, the customer-experience platform organization, and a representative dealer-advisory group.

EV charging-network integration is the back-office, protocol, and ecosystem-partnership work that determines whether a charging-network program produces a usable customer experience or a fragmented one. The work begins with a target-network footprint assessment (proprietary, partner, and roaming), an OCPP and OCPI capability audit across the charge-point management system and the e-mobility-service-provider integrations, and a Plug & Charge readiness review aligned to ISO 15118-20. A senior consultant produces an OCPP-2.0.1 charge-point-management architecture, a Plug & Charge implementation design with the public-key-infrastructure decisions documented, an OCPI-based roaming integration pattern with the partner-onboarding operating model, and a fleet-billing back-office that supports both consumer and fleet customer segments. Deliverables include the charging-network architecture decision record, the protocol-implementation design, the roaming-partner playbook, and a measurement framework that ties uptime, session-success rate, and customer-NPS to platform investment. Successful outcomes look like a charge-session-success rate sustained at the target band, a Plug & Charge experience that works across the partner roaming network, and a fleet-billing platform the commercial team can configure for new customer programs without engineering work. An engagement typically runs ten to fourteen weeks, embedded with the connected-vehicle organization, the charging-network business unit, and the cloud platform engineering team.

Supplier-portal modernization for an automotive OEM or tier-1 supplier is the data-contract and audit-evidence discipline that determines whether a customer audit becomes a six-week internal fire drill or a controlled response. The work begins with a current-state IATF 16949 evidence audit, a PPAP and APQP cycle-time baseline, and a supplier-data-contract assessment across the supplier base. A senior consultant produces a supplier-portal target architecture that consolidates PPAP, APQP, change management, and supplier scorecards, a PPAP-automation design that produces audit-grade evidence packages on customer demand, an integration design that connects the supplier portal to the QMS, Enterprise Resource Planning (ERP), and engineering-change platforms, and a supplier-onboarding operating model that manages the data-contract cadence. Deliverables include the portal architecture decision record, the PPAP-automation design, the integration patterns, and a supplier-engagement playbook for the supplier-quality function. Successful outcomes look like a customer source-audit closed without major findings, a PPAP cycle time materially reduced and sustained across the supplier base, and a supplier-quality function that operates the portal rather than working around it. An engagement typically runs ten to fourteen weeks, embedded with supplier quality, purchasing, the QMS team, and the integration-platform engineering function.