Digital twin

There is no single agreed definition. NIST says so directly in IR 8356 (February 2025) and quotes the Digital Twin Consortium's version instead: "a virtual representation of real-world entities and processes synchronized at a specified frequency and fidelity." Its own shorter wording is "the virtual (i.e., digital) representation of a physical or perceived real-world entity, concept, or notion." The twin can represent a pump, a whole plant or a process such as a charging schedule. ISO/IEC 30173:2023 sets out the concepts and terminology on the standards side.

A twin differs from a simulation model in one way: live data. A model is built once from drawings and physics. A twin is fed continuously by sensors, usually over industrial IoT or an existing SCADA system, so its state follows the real asset. NIST describes a "digital twin definition" as a machine-readable description of an entity type, and each real asset as an instance created from that definition. In software terms that is a schema for the asset class plus one live object per physical unit.

Once the twin has live state and history, it can do three kinds of work. It can show the current condition of the asset in one place, next to its documentation. It can run what-if scenarios, such as a different charging strategy or a new plant layout, without risk to the equipment. In the most advanced setups it can also send commands back to the asset. The blog post on digital twin troubleshooting shows how the first two help with outages and incident recovery.

"Digital twin" on a requirements list can mean anything from a dashboard to a closed-loop controller, so pin down which capability from the table you are buying. A monitoring twin is mostly a data engineering job. A simulation twin also needs a model and someone to calibrate it. A control twin is part of your safety case.

Ask first about the data path. The contract should name the sources (PLC, SCADA, meters, weather and market feeds), the sampling rate, how gaps and outliers are handled, and who owns the time series. Fix data quality and naming of signals at the start. Retrofitting them after dashboards and models exist is expensive.

Then decide where the twin runs and how it is secured. NIST IR 8356 lists five features that make twins a new security problem: massive instrumentation of objects, centralization of their measurements, visualization of how the object operates, remote control, and shared standards for twin definitions. Centralization is the practical one. NIST notes that if the twin is compromised, "the attacker has total access to all data about the instrumented object," and an attacker who controls the twin could change what the operator sees while issuing commands. Keep read and write paths separate, require operator confirmation for commands that move equipment, and log every write.

Access control needs more design work than buyers expect. Operators, engineers, management and external partners each see different assets and actions. Put identity in one place, for example single sign-on at the load balancer, and keep role definitions in configuration rather than scattered through dashboards.

Finally, agree how the twin is maintained. Equipment gets replaced, firmware changes signal lists and models drift. Budget for model updates and recalibration after the launch, and make the asset definitions versioned so history stays readable after a change.

For Kyoto Group we spent three and a half years on industrial IoT and digital twin software for a molten-salt thermal energy storage system, from a UX/UI MVP to a SCADA-based system that monitors and controls the flow of energy in real time.

The twin layer combined plant data with weather data and energy price analysis and included a plant performance simulation interface. In 2024 the team also worked on a web platform for planning where future solar thermal plants should go and for simulating their performance and cost from data such as solar irradiation and terrain. Plant data ran through an industrial data platform whose functions were enough for tests and prototypes but caused problems in long-term use, so for production logic we would choose a more mature runtime next time. Streamlit worked well for proofs of concept. Putting OIDC login to Azure Entra ID on the AWS load balancer took authentication out of the applications. Role-based access for the dashboards was difficult to configure and did not hold up well over time, so plan roles early.