Preparing Operators for High-Consequence Decision Making
Using a High-Fidelity Digital Twin

Edin Raković and Matthew Welsh
Prosera LLC, United States

Abstract

A high-fidelity digital twin initiative at a major liquefied natural gas (LNG) import and regasification facility addresses the preparation of operators for high-consequence decisions under dynamic plant conditions. The initiative combines alignment with the facility's native control architecture, structured scenario-based competency development, and defined governance for long-term sustainability. This paper examines modernization as the selective preservation of existing engineering and operational knowledge rather than wholesale replacement of simulation assets. A proposed review framework distinguishes assets suitable for reuse, adaptation, or replacement according to validity, supportability, and maintainability. The technical approach connects a governed production baseline to controlled twin releases, with dependencies among control logic, process models, graphics, scenarios, snapshots, and procedures managed together. Scenario design emphasizes startup transitions, equipment upsets, automated cooldown, competing priorities, and abnormal event response, with repeatable initial conditions and controlled reset. Operations retains authority over training use and qualification standards, while technical teams support configuration integrity and synchronization. The initiative has established its program foundation; the release workflows and evidence measures discussed here describe a proposed implementation and evaluation approach, not measured operating results. The central conclusion is that sustained decision readiness depends on maintaining the relationship among plant configuration, simulation behavior, training expectations, and organizational ownership.

1. Introduction

The central training problem in a high-consequence operating environment is not limited to whether an operator can reproduce a normal procedure. It also concerns whether the operator can recognize a changing condition, interpret automated system behavior, resolve competing priorities, and justify an appropriate response. The digital twin initiative considered in this paper was launched around that problem at a major LNG import and regasification facility. Its objective is to prepare new operators while establishing a sustainable environment for operations, engineering, and maintenance teams.

The accompanying presentation describes this transition as the resurrection of the digital twin. In engineering terms, resurrection means recovering the useful knowledge contained in existing assets, modernizing the implementations that limit future use, and restoring their relationship to the production plant. It does not mean retaining every legacy component or assuming that historical acceptance establishes present suitability. The distinction is between preserving knowledge and preserving technology without regard to its current purpose.

Process models, control logic, operator graphics, procedures, training scenarios, and operating experience can each remain useful while describing different configurations or expectations. The relevant modernization question is therefore not only what should be replaced, but which assets can be trusted together. A sustainable twin needs an identifiable production reference, an accepted behavioral basis, and ownership of both technical integrity and training use.

This paper presents the initiative's established design basis and the associated engineering framework. It follows three linked principles: production-accurate fidelity, structured scenario-based competency design, and sustainable governance. Detailed lifecycle workflows are presented as proposed methods for implementing those principles; quantitative performance improvement is outside the scope of this design-stage account.

2. Design Basis and Program Scope

The initiative is structured on the facility's native control architecture to maintain alignment with current production configuration, validated control logic, and priority handling representative of live plant behavior. Cross-functional reviews involving operations, automation, engineering, and training established agreement on logic expectations, abnormal event handling, and scenario design principles. A structured scenario architecture, production synchronization model, transparent configuration structure, instructor certification pathway, and role-based qualification framework form the stated program foundation.

The intended environment supports operator development and engineering validation while enabling engineering and maintenance teams to understand the configuration. This is a functional scope rather than a claim that all possible use cases have already been deployed. The facility remains unnamed, and the discussion does not specify plant equipment identifiers, operating limits, software products, or network topology.

Two distinctions are fundamental. First, technical fidelity and training effectiveness are related but separate requirements: credible simulation behavior does not by itself define a qualification standard. Second, a shared baseline does not require shared execution. An engineering test and an operator assessment can use traceable versions derived from the same production reference without operating in the same session or modifying each other's conditions. The following sections retain these boundaries when discussing reuse, synchronization, and assessment.

3. Selective Modernization of Existing Assets

3.1. Separate knowledge from its implementation

The proposed modernization approach begins with an inventory of knowledge-bearing assets and their intended uses. The review considers the process understanding embedded in a model, the operational intent represented by control logic, the context conveyed by graphics, and the lessons captured in scenarios and procedures. It then examines whether the technology carrying that knowledge remains suitable. A valuable training objective may survive even when its initial state or expected response requires revision; similarly, useful process understanding may remain relevant when its implementation needs modernization.

Three review questions define the disposition: Is the asset valid for the intended use? Can it be supported? Can it be maintained as the plant changes? These questions provide a basis for selective reuse without making age alone a reason either to retain or discard an asset. Table 1 summarizes the proposed disposition framework from the presentation.

Table 1. Proposed asset-disposition framework.

3.2. Review dependencies, not only individual assets

An asset-level review is insufficient when validity depends on other configuration items. A scenario may depend on a particular logic revision, graphic, procedure, and saved starting state. Retaining the scenario without examining those dependencies can preserve its appearance while changing the decision it teaches. The proposed review therefore connects each disposition to the assets and operating expectations on which it relies.

The review protects validated knowledge while requiring the combined environment to meet the current need. Reuse is therefore a validation decision rather than a default procurement preference.

4. Synchronized Technical Architecture and Fidelity

4.1. A governed baseline for multiple uses

Figure 1 presents the functional architecture used in the companion presentation. A reviewed production baseline informs a governed twin release that brings together native control architecture, dynamic process response, and scenario assets. Operations, engineering, and maintenance use that common foundation for different purposes. The architecture is intended to make the relationship between configuration, use, and version explicit, rather than create unrelated representations for each team.

Figure 1. Proposed functional architecture for a shared, governed twin.

A training release can remain tied to its approved scenarios and assessment expectations while engineering examines proposed behavior in a separate session. Findings from simulation can inform an engineering change, but they do not constitute authorization to change live plant control. Training execution remains separate from the live control environment. In this usage, synchronization means a controlled and explainable relationship to production, not unrestricted bidirectional connectivity or automatic updates to an active exercise.

4.2. Fidelity must support the intended decision

The proposed fidelity framework considers three connected layers: process response, control behavior, and operational context. Process response must be credible over the conditions represented by the exercise. Control behavior must reproduce the relevant logic, automated sequences, and priority handling. Operational context must provide the cues and competing demands required to practice the intended decision. A detailed model cannot compensate for incorrect automation, and familiar graphics cannot compensate for a sequence that behaves differently from the approved expectation.

These layers should be reviewed against the intended operating envelope and scenario objectives. The objective is not indiscriminate model simplification or maximum model complexity, but an agreed basis for the behavior needed in the exercise. The program's cross-functional alignment provides the foundation for that agreement.

5. Production Synchronization and Release Control

5.1. Controlled releases rather than uncontrolled copying

The initiative includes a defined production synchronization model. Figure 2 translates that principle into the proposed lifecycle described in the presentation: detect and compare, assess impact, update and test, and approve and release. Each cycle begins with an approved production reference and ends with an authorized combination of assets for a stated use.

Figure 2. Proposed production-change and twin-release lifecycle. Synchronization is subject to review, testing, and approval.

Detection and comparison identify the difference between the production reference and the relevant twin release. Impact assessment asks which behaviors, training expectations, and dependent assets may be affected. Updating and testing establish whether the revised combination behaves as intended. Approval and release establish which use is authorized. Treating these activities separately prevents a successful file transfer or configuration import from being mistaken for a validated release.

A logic change may alter more than the control configuration. It may change how a scenario develops, what the operator should recognize, which response a procedure requires, or whether a saved starting state remains suitable. The proposed process therefore evaluates dependencies across controls, models, graphics, scenarios, snapshots, and procedures rather than treating synchronization as a comparison of one database.

5.2. Release identity and configuration transparency

A release manifest provides a practical representation of the assets that belong together. In the proposed approach, it records versions, dependencies, validation evidence, and approvals. The manifest supports the transparent configuration structure identified in the initiative and connects a training or engineering session to the combination of assets on which its behavior depends.

This structure also makes known differences visible. A qualification session need not be modified during execution merely because production has changed; instead, its configuration remains identifiable while the effect of the change is assessed. A new release can then be authorized for the appropriate purpose. Engineering experiments remain distinct from approved training configurations, and the findings retain the context needed for review.

The design principle does not prescribe an update interval, transfer mechanism, or automated release tool. Those choices must be established within the implementation. The requirement developed here is that the production relationship can be explained and maintained: the baseline is known, differences are reviewed, affected behavior is tested, and the release decision is explicit.

6. Scenario-Based Competency Development

6.1. Selection and specification

The scenario architecture targets startup transitions, equipment upsets, automated cooldown sequences, priority conflicts, and abnormal event response. Selection is guided by operational risk, frequency, and training value, with repeatability and controlled reset incorporated into the framework. These considerations identify where a practice environment is needed; they are not presented as a universal scoring equation. A rare event can warrant attention when its consequences and learning value justify inclusion.

The companion presentation describes a repeatable scenario-development lifecycle: select, design, validate, run, debrief, and improve. This extends the idea of a scenario library into a maintained capability for producing and revising exercises. Table 2 identifies the proposed minimum specification used to connect the exercise to its objective and evidence.

Table 2. Proposed minimum scenario specification.

The scenario and its assessment expectations should be reviewed together. A production change can affect both the simulated response and what the operator is expected to demonstrate. An unreliable reset weakens repeatability, while inconsistent instructor expectations weaken the comparability of observations. Scenario maintenance therefore belongs within the same configuration discipline as the technical environment.

6.2. Illustrative high-consequence decision exercise

Consider an illustrative exercise that combines three of the stated scenario categories. An operator begins from a known condition while an automated cooldown sequence is underway. An equipment upset then introduces a competing priority. The exercise does not simply ask whether cooldown can be completed; it asks what changed, what the automation is doing, which condition deserves attention, and what evidence supports the next decision.

Observation is organized around recognition, prioritization, decision, action, and recovery. The expected response must be derived from the facility's approved procedures and agreed logic behavior. Operations must agree on these expectations before the exercise is used for qualification. This hypothetical exercise illustrates decision assessment rather than prescribing plant-specific actions.

Debrief connects the observed actions to the operator's interpretation of the situation. Relevant questions address what the operator noticed, what response was expected, what alternatives were considered, and where the understanding differed from the simulated behavior. Controlled reset permits another attempt from the specified starting point. The intended transition is from exposure to an abnormal event to an observable and explainable demonstration of the relevant competency.

6.3. Maintain the learning lifecycle

The select-design-validate-run-debrief-improve cycle creates a route for incorporating both production changes and training observations. A revised control sequence can initiate an impact review of the exercise; a debrief can identify a misunderstanding that requires a clearer objective or different instruction. Improvements should preserve the connection among the objective, expected response, evidence, and approved configuration. The program is then maintained as a competency-development capability rather than a static collection of exercises.

7. Governance, Qualification, and Lifecycle Sustainability

7.1. Operational authority and technical integrity

Governance ownership is explicitly defined in the initiative. Operations maintains authority over training use, scenario evolution, and qualification standards. Technical teams support configuration integrity and synchronization. This allocation separates two questions that cannot be answered by technology alone: whether the environment behaves correctly, and what an operator must demonstrate to be considered qualified.

The presentation develops this allocation by identifying maintenance contributions to equipment behavior and failure knowledge, and instructor responsibilities for consistent delivery, observation, and debrief. Table 3 combines the stated governance foundation with these proposed delivery responsibilities; it does not replace a facility-approved responsibility matrix.

Table 3. Governance foundation and proposed delivery responsibilities.

7.2. Instructor certification and operator progression

The program includes a structured instructor certification pathway and a role-based qualification framework aligned with operator progression. These pathways address different capabilities. An instructor must be able to deliver an exercise, observe performance, and conduct a consistent debrief. An operator must demonstrate the competencies associated with the role. Simulator familiarity alone does not establish instructional capability, and completion of a lesson does not by itself establish qualification.

The presentation illustrates instructor development through practice, observed delivery, and certification, and operator progression through learning, demonstration, qualification, and refresh. These illustrative stages distinguish development from demonstrated capability; qualification remains subject to the facility's approved requirements. The practical objective is continuity of training quality as instructors, operators, and scenarios change.

7.3. Design for change rather than permanent technology

Lifecycle sustainability requires the configuration structure to extend beyond the process model. Infrastructure and operating systems support software and interfaces; those support control logic, models, and graphics; those in turn support scenarios, procedures, and assessments. A change in a supporting layer can affect the validity of behavior or evidence at another layer. The proposed release manifest makes these relationships visible so that upgrades can be assessed, tested, and approved as a coherent combination.

In this context, future-proof means evolvable and governed, not immune to obsolescence. The aim is to retain operational knowledge while allowing supporting technologies to change. A one-time modernization can establish a current environment; sustained ownership and release discipline provide the mechanism for keeping that environment useful.

8. Program Status, Evaluation, and Limitations

The reported achievement at this stage is the launch of an aligned foundation: native-control-based architecture, defined scenario design principles, a production synchronization model, configuration transparency, and governance linked to certification and qualification. The engineering workflows developed in this paper describe how that foundation can be maintained and evaluated.

Evaluation should address the same three dimensions that organize the initiative. Table 4 translates them into proposed evidence questions. The emphasis is on whether the technical environment remains trustworthy, whether required decisions are demonstrated, and whether the organization can sustain both. The measures follow the companion presentation and are not reported project results.

Table 4. Proposed evidence framework for subsequent program evaluation.

Evidence must be interpreted in context. A completed change assessment establishes that the change has been reviewed; it does not alone establish that the affected behavior has passed validation. A recorded exercise demonstrates participation; it does not alone establish competence. Instructor availability is necessary for delivery, but sustainability also depends on consistent expectations and maintained configuration. These distinctions prevent activity counts from being substituted for the outcomes they are intended to support.

This account does not quantify incident reduction, qualification-time improvement, financial return, asset-reuse percentage, or fidelity accuracy. It does not establish a validated operating envelope, release cadence, network design, or completed certification outcome. Demonstrating those results requires implementation-specific evidence. The contribution is an engineering and governance framework that makes the evidence requirements visible without overstating the maturity of the initiative.

9. Conclusions

Preparing LNG operators for high-consequence decisions requires a credible practice environment and an agreed definition of performance. The initiative described here establishes a foundation that links production-accurate fidelity, structured scenario-based competency design, and sustainable governance. Its intended application extends beyond a standalone training simulator: the intended environment also supports engineering validation, accessible configuration knowledge, and long-term workforce development.

Selective modernization provides a disciplined way to preserve existing knowledge. Assets are reused, adapted, or replaced according to validity, supportability, and maintainability rather than age alone. Controlled production synchronization then maintains the relationship among models, control logic, graphics, scenarios, snapshots, and procedures. A governed baseline can support multiple teams without requiring shared execution or uncontrolled changes to active training sessions.

The proposed scenario lifecycle and ownership model connect technical integrity to the development and assessment of people. Operations defines the required performance; technical teams maintain configuration integrity; instructors and maintenance contribute to effective use and relevant knowledge. The enduring engineering objective is not to prevent change, but to preserve the ability to manage it. Resurrection becomes sustainable when useful assets remain connected to production, to the decisions they support, and to the people responsible for maintaining them.