By Emmanuel Winful and Chet Brandon
At ASSP Safety 2026 in Anaheim, Emmanuel Winful and I presented “Harnessing and Integrating Digital Twin Technology into EHS Management Systems.” This article is a follow-up to that presentation, with a deeper focus on how to actually build a functional Process Digital Twin. A link to the presentation PDF is provided below for readers who want to review the original session material.
The session introduced the basic concept: a digital twin is a digital or virtual replica of a physical object, person, or process where continuous, bidirectional, real-time data is exchanged between the digital and physical objects. That is a useful definition, as it helps EHS leaders understand that the twin is not just a viewer but an active control and intervention tool. It is worth noting, however, that this definition describes a high-maturity implementation. In practice, digital twin programs exist along a maturity spectrum from read-only condition monitoring to simulation and scenario testing to fully bidirectional real-time control. Early-stage implementations may not yet meet every element of this definition, and that is acceptable, provided the organization understands where it is on that spectrum and where it is headed.
But after the conference discussion, the more practical question is the one most leaders eventually ask:
How would we actually build one?
For this discussion, the best term is Process Digital Twin.
A Process Digital Twin is a live, data-connected model of how work, equipment, people, materials, energy, controls, and environmental conditions interact within an operating process. It is more than a drawing, dashboard, 3D model, or training simulation. The model becomes valuable when it helps people understand current conditions, anticipate what could happen next, and test decisions before making changes in the physical operation.
The value is not the technology label. The value is better control of the process.
Figure 1. A Process Digital Twin connects the physical process to a live digital representation, allowing teams to monitor conditions, evaluate risk, and improve decisions before failure occurs.
A good process twin can serve operations, maintenance, engineering, reliability, quality, environmental compliance, emergency response, training, and EHS. It is not owned by one function. It is a shared operating tool.
Start With the Problem, Not the Software
The easiest way to weaken a digital twin project is to start by shopping for platforms. That usually produces a polished visualization looking for a use case.
The better starting point is a field-level question:
What condition, decision, failure mode, or exposure are we trying to understand before it creates a problem?
That answer determines the scope.
A component twin may be enough for a pump seal, valve, bearing, or sensor. An asset twin may be needed for a pump skid, conveyor, compressor, press, robotic cell, or reactor feed system. A system twin is useful when multiple assets, utilities, controls, and people interact. A process twin is broader. It represents the way the work actually happens. The choice of scope level is not merely technical; it reflects the decision the organization actually needs to make. A team focused on predictive bearing failure does not need a process twin. A team trying to understand how pressure upset propagates across interdependent systems does.
That is why “Process Digital Twin” is the right frame. The point is not just to model a piece of equipment. The point is to model the interaction among people, assets, materials, energy, procedures, control points, environmental conditions, and decision pathways.
Figure 2. Digital twins can represent components, assets, systems, or full processes. A Process Digital Twin is often the most useful for operational leaders because it shows how work, equipment, energy, materials, procedures, and controls interact during real operations.
The first deliverable should be a clear use case, not a model. Good candidates include reducing lockout/tagout error, predicting equipment failure before loss of containment, improving ergonomic design, identifying mobile equipment interaction, evaluating emergency response routes, monitoring environmental control limits, or training workers on high-risk tasks before field execution.
Start with a problem that matters. A useful test for determining the problem: if the use case cannot be described in one or two sentences, with a measurable outcome, the scope is probably too broad to start. Narrow the problem first. Scale later.
Define the Physical Process
A process twin has to reflect reality. That means the work starts in the field.
The team needs to define the boundaries of the process. What equipment is included? What materials are involved? What energy sources are present? Who interacts with the system? Which procedures govern the work? What controls are supposed to hold? What happens during startup, shutdown, maintenance, upset conditions, and emergency response?
P&IDs, layout drawings, electrical one-lines, control narratives, standard operating procedures, job safety analyses, maintenance records, inspection findings, environmental permits, alarm histories, and incident records all become source material. For facilities covered under OSHA’s Process Safety Management standard (29 CFR 1910.119), Process Hazard Analyses, HAZOP studies, Layer of Protection Analysis outputs, Safety Instrumented System documentation, Pre-Startup Safety Reviews, and mechanical integrity records are equally important source documents and, in many cases, represent the most rigorous structured risk data the organization already has. Industrial hygiene sampling records are valuable for exposure monitoring and emissions-related use cases. Near-miss data, which is addressed later in this article, belongs in this list as well.
But the documents are only the start. Anyone who has walked down a job knows the drawing and the field condition do not always tell the same story. A good build team asks uncomfortable but necessary questions: Where can stored energy remain after shutdown? Where do people enter the line of fire? Where do pedestrians and mobile equipment cross paths? Where can a release pathway develop? Where has the procedure drifted from actual practice?
The model should be built around operational truth, not design intent alone.
Identify the Data That Matters
Once the process is defined, the team has to decide what data belongs in the twin.
More data does not always mean better insight. The useful data is the data that helps the organization detect degradation, predict failure, verify controls, or intervene earlier.
Depending on the use case, that may include pressure, temperature, vibration, flow, amperage, valve position, equipment status, emissions readings, gas detection, noise levels, worker location, ergonomic motion, task frequency, maintenance condition, inspection results, permit status, or alarm history.
The filter is simple:
Will this data help someone make a better decision sooner?
For predictive maintenance, the critical data may be vibration, temperature, current draw, runtime, lubricant condition, and failure history. For environmental compliance, it may be emissions readings, flow rates, pH, tank levels, scrubber performance, pressure drop, or permit thresholds. For ergonomics, it may be posture, force, repetition, reach distance, cycle time, and fatigue indicators. For real-time hazard identification, it may be worker location, equipment movement, temporary layout changes, geofencing, and spatial risk scoring.
Two practical data quality issues deserve attention before the model is built. First, sensor drift: a miscalibrated sensor feeding a digital twin produces systematically wrong outputs, which can create false confidence that is more dangerous than having no model at all. Calibration schedules, drift detection logic, and out-of-range flagging should be part of the data architecture from the beginning. Second, sensor failure states: the twin must have a defined behavior for what it displays and signals when a sensor goes offline or stops reporting. A gap in the data feed should never be silently treated as a normal condition.
Figure 3. A Process Digital Twin can identify changing spatial risk in real time, such as worker-equipment interaction, scaffold changes, temporary layout changes, and emerging line-of-fire exposure.
The best twins are active. They do not simply display information. They point attention to changing conditions while there is still time to act.
What Equipment Is Needed?
A Process Digital Twin sounds abstract until we break it down into the equipment required to make it function. In practical terms, the twin needs five layers.
The first is the sensor and data-capture layer. This may include pressure sensors, temperature sensors, vibration monitors, flow meters, amperage monitors, valve-position indicators, emissions monitors, gas detectors, noise monitors, proximity sensors, cameras, LiDAR, RFID tags, GPS, wearable devices, motion-capture sensors, or ergonomic wearables. The use case determines the equipment. A twin for hazardous energy control needs different inputs than one built for emissions monitoring or mobile equipment interaction.
The second is the connection and integration layer. Sensors have to communicate with the system. That may require industrial gateways, programmable logic controllers, distributed control systems, SCADA connections, wireless access points, Bluetooth beacons, cellular routers, edge devices, industrial network switches, or secure application programming interfaces. In older facilities, the issue is often not the absence of data. It is that the data is trapped in isolated systems.
The third is the edge-computing and data-management layer. Some decisions need to happen close to the process, especially where latency matters. Edge computers, local servers, data historians, and industrial PCs can clean, filter, store, and analyze data near the equipment. This is important for high-speed equipment, critical alarms, machine-interface conditions, and environmental parameters that require timely escalation.
The fourth is the modeling and analytics layer. This is where the digital representation is built and maintained. It may include CAD files, BIM models, process simulation tools, physics-based models, AI or machine-learning analytics, data historians, dashboard tools, control-system data, and EHS or maintenance management system integrations.
Figure 4. The functional anatomy of a Process Digital Twin includes data capture, connectivity, analytics, visualization, and action.
The fifth is the human interface. A twin has limited value if the output does not reach the person who needs to act. Interfaces may include control-room displays, maintenance dashboards, tablets, operator workstations, AR/VR headsets, training simulators, alarm panels, EHS software workflows, or executive dashboards.
There is one more practical requirement: cybersecurity and reliability protection. A twin connected to operating equipment becomes part of the operational technology environment. Firewalls, network segmentation, secure gateways, access controls, backup power, redundant communication paths, and monitored data storage are not afterthoughts. Organizations building process twins should reference IEC 62443, the recognized international standard for industrial cybersecurity, and CISA’s published guidance on OT network security.
The right sequence is not “buy technology, then find a purpose.” The right sequence is “define the decision, then identify the minimum equipment needed to support it.”
Build the Model Logic
The model logic is where the twin becomes useful. This is where operating limits, engineering rules, control logic, risk thresholds, and analytical models are built into the tool.
Some logic will be rule-based. If pressure exceeds a defined limit, trigger an alert. If a worker enters the swing radius of mobile equipment, flag the conflict. If an emission reading approaches a threshold, escalate. If a required energy isolation step is skipped in a simulation, stop the exercise and coach the correct sequence.
Other logic may be pattern-based. Machine learning may detect vibration changes that are hard to see in routine review. Wearable data may show fatigue patterns. AI-enabled tools may identify combinations of conditions that historically preceded quality failures, equipment breakdowns, environmental deviations, or injury events.
The distinction matters. Traditional rule-based software is strong when the rules are clear. AI-enabled tools are useful when patterns are complex or ambiguous. But AI outputs still need verification. A confident answer is not the same thing as a correct answer.
The twin should support judgment. It should not replace engineering review, operator knowledge, field verification, or management accountability.
Validate Against the Field
A digital model that does not match the physical process will create false confidence. That is worse than having no model at all.
Validation should include field walkdowns, operator review, engineering review, maintenance review, EHS review, and scenario testing. The team should compare model outputs against actual sensor readings, known operating conditions, historical incidents, near misses, maintenance findings, failure modes, and abnormal events.
The test is straightforward:
Does the twin accurately represent the process?
Does it identify the conditions that matter?
Does it help people make better decisions?
If not, it is not ready to scale.
This is also a good place to compare high-performing and low-performing operations. If one line, crew, site, or operating condition consistently performs better, the twin may help show why. The answer may be better sequencing, equipment condition, layout, training, alarms, staffing, supervision, or control discipline. The point is not only to find what failed. The point is to transfer what works.
A Practical Example: The LOTO Process Digital Twin Built in ChatGPT
One practical follow-up to our ASSP Safety 2026 presentation is a model LOTO Process Digital Twin created in ChatGPT. Before describing it, a definitional note is warranted: Given that the twin was not connected to a physical reactor, the example does not fully meet the bidirectional, real-time data exchange described at the opening of this article. It is more precisely a decision-practice simulation scaffold: a structured, scenario-based tool, based on a physical process, that makes hazardous-energy isolation decisions visible and repeatable in a safe learning environment.
Figure 5. A lockout/tagout Process Digital Twin can allow employees to practice hazardous energy isolation in a safe, repeatable environment before performing the work in the field.
This tool is not intended to replace a company’s lockout/tagout procedure, field verification, authorized employee training, or site-specific energy-control program. It demonstrates how a process twin can support interactive learning and decision-making practice.
In the presentation, we showed the concept of a LOTO process twin as a safe, repeatable simulator for practicing energy isolation before field execution. The example allows a learner to work through a feed pump and feed line isolation scenario, make decisions, receive feedback, and see the consequences of incorrect sequencing before doing similar work in the field.
That kind of practice matters. In the field, the hard part of LOTO is not usually reciting the basic steps. The hard part is recognizing the real energy pathways, understanding the sequence, identifying stored or residual energy, and knowing what can go wrong when a step is missed or performed out of order.
The ChatGPT-based LOTO twin is designed to make those decisions visible. A user can work through questions such as: What equipment needs to be isolated? Which valves must be closed? Where could pressure remain trapped? What must be locked and tagged? How should zero energy be verified? What happens if the pump is isolated but the line remains pressurized? The tool should never be the sole or primary means of LOTO training. It is a supplemental practice aid, not a substitute for authorized-employee training, procedure-specific competency, or field verification required by the employer’s energy-control program under 29 CFR 1910.147.
It also demonstrates an important point. A useful process twin does not have to begin with a fully instrumented facility or a large enterprise software project. It can begin with one high-risk task, one clearly defined process, and one decision pathway where better understanding can reduce serious risk.
A first-generation version may use written process logic, prompts, diagrams, and scenario-based questions. A more advanced version may incorporate equipment data, valve status, pressure readings, procedure libraries, training records, or augmented reality. A fully mature version may connect to live operational data and maintenance planning systems.
The development path should be disciplined: define the hazardous energy scenario, map the equipment and isolation points, build the decision logic, test the simulation against the actual procedure, validate it with qualified operations, maintenance, engineering, and EHS personnel, and use it as a training and planning aid rather than a substitute for authorized procedures or competent supervision.
A LOTO twin should be governed like any other safety-critical training or decision-support tool. It needs review, version control, and updates when equipment or procedures change.
Connect the Twin to the Management System
A process twin should strengthen the systems already used to manage work.
That includes risk assessment, management of change, operating procedures, training, preventive maintenance, inspections, emergency planning, incident learning, corrective actions, and leadership review.
The connection between the twin and the Management of Change (MOC) system requires careful consideration. If physical changes occur, such as installing new equipment, modifying layouts, revising procedures, or shifting staffing, and the twin is not updated accordingly, it risks providing inaccurate information instead of serving as a reliable control tool. The twin should be managed as a controlled document within the MOC framework, not just a system that passively receives notifications. This involves establishing who has authority to approve updates, how version control is maintained, and what triggers a mandatory review of the model. An outdated twin is not neutral; it can become a liability.
For facilities subject to OSHA PSM (29 CFR 1910.119), the twin can support the work processes associated with Process Hazard Analysis revalidation, mechanical integrity, operating procedure updates, incident investigation, and emergency planning. For facilities subject to the EPA Risk Management Program (40 CFR Part 68), twin data on process conditions, release pathways, and control effectiveness may inform program analysis, planning, and internal documentation. Organizations should consult with legal and regulatory counsel to understand how twin outputs are characterized under applicable recordkeeping and disclosure requirements before integrating them into formal compliance documentation.
For electrical energy control specifically, NFPA 70E provides the recognized standard for safe work practices around electrical hazards. A LOTO or electrical isolation twin should be developed and validated against NFPA 70E requirements, not independently of them. ISO 55000, the international standard for asset management, provides a useful framework for integrating twin outputs with maintenance strategies, reliability programs, and lifecycle planning
The strongest twins eventually become part of the normal work rhythm. They inform pre-job planning. They support MOC reviews. They guide preventive maintenance. They test emergency response plans. They help teams see where controls are holding and where they are starting to degrade.
The twin does not replace the procedure, inspection, work permit, or supervisor. It makes those systems more visible and easier to test before the stakes are real.
Phase the Implementation
Start small and scale with discipline.
Phase 1: Define the use case. Select one meaningful operating problem with measurable value.
Phase 2: Map the physical process. Define assets, boundaries, workflows, energy sources, materials, people, operating states, controls, and failure modes.
Phase 3: Select the data. Identify the minimum information needed to monitor condition, detect change, predict risk, and support action.
Phase 4: Build and test the model. Create the digital representation, apply operating logic, set thresholds, and simulate normal, abnormal, and emergency conditions.
Phase 5: Validate with operators and technical experts. Compare the model to actual field conditions and correct inaccuracies.
Phase 6: Integrate with management systems. Connect outputs to training, inspections, maintenance, MOC, emergency planning, corrective actions, and leadership review.
Phase 7: Scale based on value. Expand after the first use case proves it improves decisions.
Figure 6. Process Digital Twins should be implemented in phases: define the use case, map the system, connect data, validate the model, integrate with management systems, and scale only after value is proven.
The most impressive twin is not always the most useful one. Build the version that helps people control the work.
Build the Team Before You Build the Twin
Process twins require shared ownership. EHS cannot build them alone. IT cannot build them alone. Engineering cannot build them alone.
A capable team includes operations, engineering, maintenance, EHS, IT, data analytics, frontline employees, and leadership sponsors. Operators understand how the job is really done. Maintenance understands failure and repair history. Engineering understands design intent and system constraints. EHS understands exposure, compliance obligations, control effectiveness, and incident learning. IT and data teams understand architecture, integration, cybersecurity, and analytics.
Shared ownership requires defined governance. The team should establish before the build begins who owns the twin, who has authority to approve changes to the model logic, how version control is managed, and the escalation path when model outputs conflict with operator field judgment. Without those answers, cross-functional teams often reach consensus during the build phase and then fragment during the operational phase when disagreement about the model’s accuracy or authority creates pressure. A RACI framework defining who is Responsible, Accountable, Consulted, and Informed for each decision category is a practical tool for establishing clarity early.
Without that mix, the project can go wrong in two predictable ways: technically elegant but operationally irrelevant, or operationally interesting but technically fragile.
This is not just an IT project. It is a performance, reliability, and risk-control project enabled by technology.
Manage the Risks
Process twins create new capability, but they also create new responsibilities.
Bad data can drive bad decisions. A weak model can create false confidence. Overreliance on AI can reduce field verification. Cybersecurity gaps can create operational exposure. Poor data governance can create privacy, labor relations, confidentiality, or compliance concerns. A model that is not maintained can become outdated quickly as equipment, layouts, procedures, staffing, and operating conditions change.
Every process twin should have an owner, a defined purpose, approved data sources, validation criteria, update frequency, cybersecurity review, access rules, and revision triggers. Treat it like a management system tool, not a one-time technology project.
One rule should hold: the twin must improve control of the actual process. If it does not, it is just a visualization.
The Future Is Foresight
Process Digital Twins are not replacements for leadership, engineering discipline, field knowledge, or worker engagement. They are tools that make process conditions and emerging risk more visible before failure occurs.
The future will not be built only on better dashboards and after-the-fact metrics. It will be built on live systems that help teams see weak signals, test scenarios, verify controls, and act earlier. Our presentation closed with the point that digital twins are live, intelligent models powered by IoT and AI, and that practical, proactive, predictive, and preventive applications already exist.
The organizations that benefit most will be the ones that start with real operating problems, build carefully, validate relentlessly, and connect the twin to the way work is actually managed.
In operations, maintenance, quality, sustainability, and EHS, the measure of innovation is not how advanced the tool appears. The measure is whether the process is better understood, better controlled, and less likely to fail.
That is how a Process Digital Twin becomes more than a model.
It becomes a working part of prevention.
About the Guest Author
Emmanuel Winful, CSP, MPH, MS is a health and safety leader with experience across higher education, underground mining, environmental and recycling operations, and the oil and energy sector. He is currently a Health and Safety Manager at Auburn University’s Samuel Ginn College of Engineering and serves part-time as a Workplace Safety Consultant with the National Safety Council.
Emmanuel’s work focuses on developing, organizing, and implementing environmental, health, and safety management-system initiatives that drive continuous improvement. He has a proven record of leading complex projects using risk-based safety strategies, strengthening employee and management engagement, and improving organizational safety performance.
He holds a Master of Public Health in Environmental Health Science from Georgia Southern University, a master’s degree in Industrial and Systems Engineering from Auburn University, and a Graduate Certificate in Occupational Safety and Ergonomics from Auburn University. He is also pursuing a PhD in Industrial and Systems Engineering at Auburn University. Emmanuel is a Certified Safety Professional and brings expertise in safety engineering, emergency management, lockout/tagout, ergonomics, OSHA compliance, and environmental health.
LeadingEHS.com 