Xpdeep
Talk to us

AUTOMOTIVE

New vehicle functions, once state estimates carry explicit conditions.

Better-characterized learned estimates of physical state can support new vehicle functions and efficient embedded models. They also give engineering a basis for examining conservative design margins held for uncertainty.

DECISIONS ARE TAKEN DOWNSTREAM: NOT ON THE IMAGE DETECTOR

01 VEHICLE STATE

Virtual sensing lets engineers examine which measurements and margins remain necessary.

Xpdeep builds deep virtual-sensor models from signals already available in the vehicle, and exposes which inputs and temporal structures carry each estimate. Engineers can then examine whether a physical measurement or a conservative design margin is still required. Customer engineering makes that determination.

  1. PHYSICAL SENSING
  2. MODELLED STATE
  3. EMBEDDED DECISION

ILLUSTRATIVE: AVAILABLE INPUT SIGNALS → ESTIMATED COMPONENT STATE

POTENTIAL VALUE

  • Product capability: a modeled state that may support a function without a dedicated sensor, subject to customer engineering validation.
  • Sensing: an evidence base for deciding whether a physical measurement remains necessary
  • Embedded resources: a smaller footprint on the target
  • Design margin: evaluate material carried to compensate for uncertainty in the estimated state.

DESIGN MARGIN

An accurate virtual sensor, its structural explanation and attributed domain state can help engineering assess whether less or cheaper material is feasible within physical and engineering constraints.

EVIDENCE · Virtual-sensor models have been delivered and validated by customer engineering. Series deployment is a separate customer decision.

Explore embedded technology →

02 STRUCTURAL UNDERSTANDING AND DESIGN

Train once.
Then see what the model actually needs.

  1. FULL INPUT SET
  2. STRUCTURAL READING
  3. ENGINEERING REVIEW
  4. REDUCED INPUT SET

105 → 19

INPUT VARIABLES

Up to 82% fewer input variables; 105 reduced to 19 at equal or better accuracy.

INDEPENDENT PROGRAMME EVALUATION

Input reduction is an engineering decision made with the model structure in view, not an automatic cut.

GLOBAL VS LOCAL

GLOBAL IMPORTANCE

IN PREDICTIVE REGION R3

An input that looks globally unimportant may still matter in a specific predictive region.

Not associated with an automotive client, and not a sensor-reduction percentage: fewer input variables does not by itself remove a physical sensor.

03 DESIGN MARGINS

A margin held for uncertainty can be examined once the estimate shows where it remains valid.

Some thermal, electrical and mechanical designs retain additional margin because the relevant physical state cannot be characterized precisely enough. When a learned estimate exposes its structure and domain of validity, engineering can examine which part of that margin compensates for uncertainty and which part reflects physical or regulatory limits that stay in force.

WHAT ENGINEERING RECEIVES

  1. 01

    Structural explanation of the estimate

  2. 02

    Attributed domain state: which inputs or conditions drive a departure

  3. 03

    Learned regions where the estimate is well or poorly supported

  4. 04

    Evidence for the engineering review of a margin

WHERE IT APPLIES

  • BMS temperature intelligence
  • Thermal management
  • Charge optimisation
  • Power / energy state estimation

Any change to a design margin is an engineering decision validated by the OEM or Tier-1. Margin recovery is an opportunity to establish on each application, not a delivered result.

04 EMBEDDED FRUGALITY

A Native model can provide structural understanding with a smaller deployed footprint.

UP TO 35×

FASTER INFERENCE

Selected validated results across Confiance.AI and client programmes

UP TO 50%

SMALLER MODELS

Selected validated results across Confiance.AI and client programmes

8% vs 12% ROM

VIRTUAL TEMPERATURE SENSOR

Virtual temperature sensor: Xpdeep model 8% of ROM; state-of-the-art comparison model 12%, on the same embedded target. Unnamed European Tier-1.

Retrofit adds an explanation layer whose compute and memory overhead are measured on the target.

On time-series data, Xpdeep models achieve accuracy at least equivalent to standard deep learning and frequently superior.

Models are profiled on the customer’s target in the first engagement.

EMBEDDED TARGET · ECU / BOARD

05 PERCEPTION

A perception model should know when the road has moved beyond what it learned.

Xpdeep connects to the customer’s or supplier’s learned perception model. Xpdeep does not supply perception models or sensors.

Structural integration requires read access to the PyTorch architecture and weights. Supplier-owned models require the supplier’s cooperation.

DOMAIN STATE · INSIDE KNOWN DOMAIN

STRUCTURAL EXPLANATION · ATTRIBUTED

  1. PERCEPTION MODEL
  2. DOMAIN VALIDITY GATE
  3. DOWNSTREAM ADAS / PLANNING SYSTEM

TECHNICAL BOUNDARY: Image-level prescription: not available; under study.

Structural explanation

Attributed domain state

Novel-class detection where appropriate

Domain-validity gating

TECHNICAL NOTE: DEMONSTRATED SCOPE

YOLO, D-FINE, DETR, 3D camera detection, BEVFusion-type camera / LiDAR fusion, ViT video. Structural analysis of these learned perception models has been demonstrated. Domain state gates the downstream system; no prescription is made at image level.

06 PRODUCT VARIANTS

When the hardware changes, the model should not always start from zero.

  1. VARIANT N
  2. STRUCTURAL DIAGNOSIS
  3. TARGETED LOCAL CORRECTION (NATIVE)
  4. VALIDATION
  5. VARIANT N+1

REST OF MODEL FROZEN

WHEN SOMETHING CHANGES

  • New sensor
  • New component
  • Supplier change
  • Hardware revision
  • Product variant
  • Environment change

OUTCOMES TO ESTABLISH

  • Diagnosis time.
  • Engineering hours and retraining scope.
  • Regression-testing scope.
  • Revalidation effort.

Targeted editing is available in Native mode. The economics of model-family evolution across variants remain a hypothesis to establish on the customer’s application; reuse depends on what changed and requires validation.

INTEGRATION

Go Native for the full lifecycle.
Use Retrofit to retain an existing model.

RETROFIT

BEST FIT

  • Supplier-owned or existing PyTorch model
  • Predictive architecture, weights and predictions unchanged
  • Structural understanding
  • Attributed domain state
  • Production decision inputs

REQUIREMENTS

  • Read access to the PyTorch architecture and weights
  • Representative inputs
  • Supplier cooperation where supplier-owned

NATIVE

BEST FIT

  • New model generation
  • Embedded deployment
  • KPI alignment
  • Input reduction / frugality
  • Targeted local editing
  • Controlled evolution
  • Full three loops

Native is the recommended path for the full three loops. Optimization, input reduction and targeted correction require Native.

07 OEM OPPORTUNITIES

Explore condition-aware performance inside fixed OEM limits.

A product envelope must cover different assets, ages, environments and usage conditions.

OPERATING ENVELOPE

  1. FACTORY / STATIC ENVELOPE
  2. ASSET STATE + HISTORY + DOMAIN STATE
  3. CONDITIONAL OPERATING ENVELOPE
  4. ACT / HOLD / ESCALATE
  5. FACTORY FALLBACK PRESERVED

POTENTIAL ECONOMIC SURFACES

  • Usable capacity
  • Efficiency
  • Availability
  • Lifetime
  • Premium performance tiers
  • Aftermarket performance

Longer-term opportunity, not a delivered result. Illustrative OEM pattern; commercial adoption and operating limits remain with the OEM.

Explore OEM opportunities →

DATA · VALIDATION · EVIDENCE

What automotive engineering measures, and where the evidence stands.

RELEVANT DATA AND MODEL TYPES

  • Vehicle bus, powertrain, thermal and electrical time series
  • Tabular calibration and test data
  • Camera, LiDAR or fusion perception models (customer- or supplier-owned)

WHAT THE CUSTOMER MEASURES OR VALIDATES

  • Estimate accuracy and domain coverage on its own test campaigns
  • Footprint and latency on the embedded target
  • Whether a physical measurement or design margin can change, through its safety and validation process
  • Revalidation scope for each product variant

PUBLISHABLE EVIDENCE AND MATURITY

ENGINEERING-VALIDATED
Virtual-sensor models delivered and validated by customer engineering; 8% vs 12% ROM on an unnamed European Tier-1’s embedded target.
DEMONSTRATED
Structural analysis of learned perception models; 105 → 19 input variables at equal or better accuracy (independent programme evaluation, not an automotive client).
AVAILABLE IN NATIVE MODE
Targeted editing and controlled evolution.
HYPOTHESES
Model-family evolution economics, design-margin recovery and OEM condition-aware performance offers.

Automotive evidence and programme status.

STATUS RAIL

  1. ENGINEERING-VALIDATED

    Virtual-sensor models delivered and validated by customer engineering. On an unnamed European Tier-1's own embedded target, the Xpdeep virtual temperature sensor used 8% of ROM vs 12% for its state-of-the-art model.

  2. COMPLETED

    Tier-1 robotized-equipment project completed.

  3. UNDER CONSIDERATION

    Virtual-sensor model finished and under consideration for adoption.

  4. FIRST PHASE COMPLETE

    BMS temperature model completed first phase and awaits additional data.

  5. NEXT

    Charge-optimisation and ADAS models are about to start.

  6. EMBEDDED PROGRAMME

    Embedded execution is worked on with Infineon in the European MOSAIC project.

Completed model work, customer engineering validation, programme status and series deployment are distinct stages. No series deployment is claimed here.

Automotive engineering boundaries.

EXPAND

  • Development runs on Linux; RTOS / middleware porting is done with OEM, Tier-1 or integrator.
  • No ISO 26262 or SOTIF certification by Xpdeep; ASIL decomposition and safety case remain with OEM / Tier-1.
  • Xpdeep contributes evidence for SOTIF and ISO/PAS 8800.
  • Perception models: image-level prescription not available; under study.
  • The customer’s surrounding system defines and authorizes actions.
  • Attributed domain state covers the retained model inputs; alone, it does not authorize action or establish system safety.
  • Structural justification does not automatically establish physical causality.
  • Minimal means minimal feasible under the stated constraints and optimization procedure.
  • Targeted editing and controlled correction require Native mode.
  • System validation and certification remain with the customer and relevant authority.
  • Reduced requalification scope requires application-specific evidence and acceptance.

START WITH ONE FUNDED AUTOMOTIVE PROBLEM

Start with the problem
your programme already funds.

  • VIRTUAL SENSING

    A state currently measured physically or estimated indirectly

  • SUBSYSTEM DESIGN

    A thermal, electrical or mechanical design carrying margin for uncertainty

  • EMBEDDED MODEL

    A footprint or performance problem on the target

  • PERCEPTION MODEL

    A learned perception model that needs structural analysis or explicit domain awareness

  • PRODUCT VARIANT

    A model that must evolve with hardware or supplier changes

An existing autonomous decision is not required.

Phase 1 is a funded engagement, typically three to six months, on a consequential model, decision, function or programme you have prioritized. Agree the economic, operational, quality, mission, product or assurance success criterion at scoping; work on your data within your engineering environment and constraints.

Xpdeep supplies model-level technology and repeatable software deployment, not a replacement engineering lifecycle. Your teams and implementation partners can integrate and validate the model using your own tools and test processes.

  1. 01 →

    One funded problem

    A model, engineering problem, product function, subsystem or decision the business already owns.

  2. 02 →

    Agreed criterion

    Data, duration, success criterion and validation method defined at scoping.

  3. 03 →

    Evidence on your application

    Results assessed through the customer’s validation process; a side-by-side model comparison is one possible method.

  4. 04

    Define the extension

    Identify the possible Phase 2 scope at the start; use Phase 1 evidence to determine its scope.

Talk to us →Explore Technology →Back to Industries →