Digital twin development

Custom Digital Twin Development for Business Operations

Salt develops custom digital twin solutions that connect a model of physical assets or business processes to changing operational data. Start with one site, asset group, or workflow, then build the views and decision support your team needs. Sensor integration, simulation, and predictive features are scoped around available data and validation requirements.

Example use cases

Which operations could a digital twin help your team understand?

These are examples, not a complete list of what we can build. We develop custom solutions around your business process, including use cases not listed here. Delivered client work is identified separately below.

01Warehousing and logistics

Warehouse asset & condition model

Inspection findings, asset locations, and repair status live in separate records.

Start with
An asset register, location hierarchy, inspection records, and approved status updates.
What we can build
Connect assets, locations, conditions, and repair events in a model with source timestamps and ownership.
Your team gets
A current operational view showing affected assets, missing updates, and outstanding actions.

Plan for: Agree asset identifiers, update frequency, and how inspectors verify the model against the physical site.

Discuss this use case
02Manufacturing operations

Production process monitoring

Teams cannot easily connect delays across machines and production steps.

Start with
Process steps, equipment events, job records, and permitted machine or gateway feeds.
What we can build
Model the relationships between jobs, stations, and equipment; show state changes and investigate bottlenecks.
Your team gets
A shared view of the process and the events behind interruptions.

Plan for: Review equipment connectivity and data quality first. Throughput simulation needs a calibrated model; visibility alone is not simulation.

Discuss this use case
03Maintenance teams

Asset condition & maintenance planning

Readings, maintenance history, and open work orders are disconnected.

Start with
Asset specifications, available condition readings, service history, and work-order records.
What we can build
Associate observations and maintenance events with each asset; flag agreed thresholds and route items for review.
Your team gets
An asset-level history and prioritized review queue with supporting evidence.

Plan for: Define sensor reliability and alert ownership. Predicting failures requires suitable historical examples and separate evaluation.

Discuss this use case
04Facilities operations

Facility systems & resource use

Teams struggle to explain changing consumption or equipment status across a site.

Start with
A facility and equipment hierarchy, meter readings, operating schedules, and approved system access.
What we can build
Connect equipment and zones to time-stamped observations; compare agreed baselines and surface exceptions.
Your team gets
A traceable view of which systems need investigation and when conditions changed.

Plan for: Separate monitoring from control. Changes to physical equipment require authorized operators and appropriate safety controls.

Discuss this use case

Don’t see your use case? We can build around it.

Your project can adapt these examples, combine several workflows, or solve a different problem. Tell us what you need to achieve and which systems you use. We’ll define the scope, integrations, and a practical first release with you.

Discuss your workflow

The solution in action

From a daily task
to a connected workflow.

An illustrative flow to make the scope tangible. We adapt the steps, roles, and controls to your business.

  1. 01

    Connect approved sources

    Map assets, processes, identifiers, and observations from existing systems or gateways.

  2. 02

    Maintain the operational model

    Update relationships and state with timestamps, validation, and visible freshness.

  3. 03

    Investigate and act

    Review exceptions, compare agreed scenarios where validated, and send approved work to the responsible team.

What we can build

The capabilities behind the workflow.

Asset & process modeling

Represent entities, relationships, states, and business rules for the selected operation.

Data integration & freshness

Connect agreed APIs, events, or telemetry feeds and surface missing or stale observations.

Operational views

Build role-based views of conditions, history, exceptions, and work in progress.

Scenario evaluation

Scope and calibrate scenario models where data and domain expertise support a meaningful comparison.

Workflow integration

Connect approved maintenance or operations systems with review and traceability.

Access & audit controls

Define read and action permissions, source provenance, and records of important changes.

Related operational software experience

Warehouse rack audit & safety system

Salt’s warehouse rack audit and safety system demonstrates asset inspections, recorded findings, and repair follow-up. It is related operational software experience, not a claimed digital twin deployment. A twin’s telemetry, state model, and any simulation require their own agreed scope and validation.

Explore what Salt delivered
Inside the project
  • Mobile inspection schedules and task tracking
  • Condition views and severity classification
  • Issue verification and maintenance follow-up

Read the project scope and implementation details to assess the fit for your business.

Plan before you build

Agree on the inputs.
Know what success means.

Systems, data & access

An accountable operations owner, an asset or process inventory, source-system access, stable identifiers, and agreed freshness and accuracy requirements. Review gateways, connectivity, retention, and data ownership. Hardware procurement, instrumentation, engineering simulation, and safety-critical control require explicit specialist scope.

What to measure

Establish baselines for model coverage, source-to-view delay, state accuracy against observed operations, missing updates, and time to investigate an exception. Evaluate any scenario or prediction against agreed reference cases before using it for operational decisions.

A focused first release

One asset group or process at one site, one agreed data feed, a defined state model, and one operational decision to support.

Delivery with SPARK

Make the next decision with evidence.

Explore the SPARK framework

Define the workflow, test the uncertain parts, and release an agreed scope. Use the pilot to decide what belongs in the next stage.

  1. Agree on the scope. Map users, exceptions, systems, and acceptance criteria.
  2. Test the first workflow. One asset group or process at one site, one agreed data feed, a defined state model, and one operational decision to support.
  3. Build and validate. Review working software, access boundaries, and integration failures.
  4. Release and improve. Establish a baseline using the agreed measures and review what users need next.

Before you decide

Questions buyers ask.

Connected expertise

Explore your next step.

Data & Analytics

Let’s define a useful first release

Tell us where the work gets stuck.

Bring your current workflow, the systems involved, and the outcome your team needs. We’ll help identify a practical starting scope.

Discuss your workflow