Xpdeep
Talk to us

AUTOMOTIVE

New vehicle functions, once state estimates carry explicit conditions.

Explainable vehicle-state estimates and attributed domain conditions can support new functions, reduced sensing requirements and efficient embedded models. They also give engineering a basis for evaluating design margins held for uncertainty.

DECISIONS ARE TAKEN DOWNSTREAM: NOT ON THE IMAGE DETECTOR

01 VEHICLE STATE

Some of the most valuable signals should not need a physical sensor.

Xpdeep can build deep virtual-sensor models from the signals already available in the vehicle, while exposing which inputs and temporal structures carry the estimate.

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

ILLUSTRATIVE: AVAILABLE INPUT SIGNALS → ESTIMATED COMPONENT STATE

POTENTIAL VALUE

  • Product capability: a state the vehicle can use without a dedicated sensor
  • Sensing burden: fewer physical sensors to fit and maintain
  • 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.

Explore embedded technology →

02 EMBEDDED INTELLIGENCE

Vehicle intelligence should know when its own estimate remains valid.

PRIMARY INFERENCE

BATTERY / THERMAL STATE

PREDICTEXPLAINCHECK DOMAIN

SAME FORWARD PASS , Prediction and explanation together.

WHEN AN INTERVENTION IS USEFUL

PRESCRIBE WHERE APPLICABLEJUSTIFY

SEPARATE INFERENCE , Run only when an intervention is useful.

SYSTEM RULE

ACTHOLDESCALATE

Prediction and structural explanation share one forward pass. Prescription is a separate inference, invoked when useful on temporal and tabular stages.

On temporal stages, an Xpdeep model can return the full decision object:

  1. 01

    Prediction

  2. 02

    Structural explanation

  3. 03

    Attributed domain state

  4. 04

    Minimal feasible intervention under constraints

  5. 05

    Structural justification

WHERE IT APPLIES

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

03 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. Domain state gates the downstream system; no prescription is made at image level.

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.

SELECTED VALIDATED RESULTS ACROSS CONFIANCE.AI AND CLIENT PROGRAMMES

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.

EMBEDDED

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

UP TO 35×

FASTER INFERENCE

Independent programme evaluation

UP TO 50%

SMALLER MODELS

Independent programme evaluation

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

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.

04 PRODUCT EVOLUTION

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 correction is available in Native mode. Its economic value when moving between product variants is established on the customer’s application; reuse depends on what changed and requires validation.

05 OEM ECONOMICS

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

Illustrative OEM transformation pattern. Commercial adoption and operating limits remain with the OEM.

Explore OEM opportunities →

Automotive work already underway.

STATUS RAIL

  1. COMPLETED

    Tier-1 robotized-equipment project completed.

  2. UNDER CONSIDERATION

    Virtual-sensor model finished and under consideration for adoption.

  3. FIRST PHASE COMPLETE

    BMS temperature model completed first phase and awaits additional data.

  4. NEXT

    Charge-optimisation and ADAS models are about to start.

  5. EMBEDDED PROGRAMME

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

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 AUTOMOTIVE DECISION

Start with the decision
your programme already funds.

  • VIRTUAL SENSING

    A state currently measured physically or estimated indirectly

  • BMS / THERMAL

    A temporal model tied to temperature, energy or charge

  • EMBEDDED MODEL

    A footprint / performance problem on the target

  • PERCEPTION DOMAIN

    A learned perception model that needs explicit domain awareness

  • PRODUCT VARIANT

    A model that must evolve with hardware or supplier changes

Run an Xpdeep model alongside your existing model for an agreed number of weeks. Compare performance on the same data against agreed KPIs, using your own validation chain.

An Xpdeep model is a PyTorch model with a different architecture. Customers can validate it using their own tools and test processes.

  1. 01 →

    One funded decision

    A model or decision loop the business already owns.

  2. 02 →

    Agreed comparison

    Data, duration and KPIs defined at scoping.

  3. 03 →

    Evidence on your application

    Side-by-side results using the customer’s validation process.

  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 →