Virtual Commissioning

Executive summary

Virtual commissioning (VC) is the engineering practice of validating PLC, robot, motion, safety, and process-control logic against a digital model of a machine, cell, or line before physical installation. It sits between mechanical/electrical design and physical startup. The core commercial claim is that VC reduces on-site commissioning time, rework, and launch risk. This note finds that claim mostly in vendor technical documentation and one peer-reviewed academic survey; it does not find an audited, filing-level ROI figure from an industrial company.

The strongest source retrieved here is a peer-reviewed survey by Lee and Park, Survey on the virtual commissioning of manufacturing systems, Journal of Computational Design and Engineering, DOI 10.7315/JCDE.2014.021, published 2014-07-01. That paper is Tier 1 for the technical definition, taxonomy, and general failure modes. A granted patent was not verifiable in this offline session; therefore the patent-moat portion of this note is incomplete. A human second-pass should retrieve a USPTO/EPO/WIPO granted patent and record the grant number, assignee, grant date, and claims. No load-bearing technical claim in this note depends on a patent.

Vendor pages from Siemens, Rockwell Automation, Dassault Systèmes, MathWorks, and ABB provide Tier 2 adoption context. Those pages are self-reported marketing/technical documentation; they support the existence and direction of the toolset, but they do not independently prove performance.

Definition, scope, and taxonomy

2.1 What virtual commissioning is

Lee and Park define virtual commissioning as a simulation-based validation method for control programs of automated production systems. The core differentiator from traditional CAD or digital mock-up is that the control program is executed against a simulated plant model, so logic errors can be observed before hardware exists. The survey describes a workflow that includes modeling the mechanical system, sensors and actuators, and the control logic [S1].

In plain engineering terms, VC connects the control code to a model that reacts like the physical machine. A PLC output to “open clamp” changes the simulated clamp; a simulated sensor then reports the clamp state back to the PLC. If the clamp is not modeled correctly, the test is not useful. That model-fidelity limitation is repeated throughout the literature [S1].

2.2 Common VC modes

The literature and vendor documentation generally recognize several modes. I am stating them as definitions, not as verified performance claims.

1. Model-in-the-loop (MIL): Control logic is tested entirely inside the modeling tool. This is often the earliest stage.
2. Software-in-the-loop (SIL): The actual control application code, often exported from the PLC engineering environment, runs against the plant model.
3. Hardware-in-the-loop (HIL): A physical PLC, robot controller, or industrial PC runs against a real-time plant simulation. This validates communication, scan-time, and I/O behavior more closely than pure software simulation.
4. Operator training and HMI validation: The simulated plant is connected to the runtime HMI/SCADA, so operators can train and the HMI can be checked before onsite work.

Lee and Park treat VC as broader than HIL/SIL, spanning the whole pre-commissioning validation sequence [S1]. Vendor pages often blur these modes. Siemens Tecnomatix Process Simulate positions virtual commissioning in robot cell simulation and PLC validation workflows [S2]. Rockwell Emulate3D positions itself as a dynamic digital twin for control system testing [S3].

2.3 What VC is not

VC is not a physical commissioning replacement. It is a pre-validation environment. It is also not the same as a full-lifecycle digital twin, though a virtual commissioning model can later evolve into a digital twin. ISO 23247-1:2021 defines a digital twin framework for manufacturing and is broader than VC [S8]. The relationship is that VC can be a digital-twin use case: a virtual representation used to validate control logic before physical deployment.

Technical architecture and tooling

3.1 Reference stack

A virtual commissioning environment usually requires these layers, assembled from vendor pages and the academic source:

This stack is an inference from multiple independent vendor pages and standards; it is not a single-vendor architecture. The existence of each tool is source-bound, not a performance claim.

3.2 Standards and interoperability

Interoperability is a recurring bottleneck in virtual commissioning because the mechanical model, controls model, and automation code often come from different tools. The Functional Mock-up Interface (FMI) is the main open model-exchange/co-simulation standard used for this purpose. The FMI project defines Functional Mock-up Units (FMUs) that can exchange models between tools [S7].

ISO 23247-1:2021 provides a digital twin framework for manufacturing. It does not replace FMI but gives a data/architecture context for manufacturing digital twins [S8]. If a VC model is intended to become an operational digital twin, the ISO framework becomes more relevant after commissioning.

3.3 Vendor landscape

• Siemens Tecnomatix Process Simulate: Markets robot and production-line simulation, with virtual commissioning workflows for planning and validating automation. The product page is Tier 2 self-reported [S2].
• Rockwell Emulate3D: Dynamic digital twin and control system emulation for virtual commissioning. Rockwell describes it as part of FactoryTalk DesignSuite [S3].
• Dassault DELMIA Virtual Commissioning: Virtual commissioning workflow on the 3DEXPERIENCE platform, marketed toward industrial equipment and manufacturing industries [S4].
• MathWorks: Positions Simulink and Simscape for model-based virtual commissioning, especially where closed-loop control and physical behavior matter [S5].
• ABB RobotStudio: Robot-specific simulation and offline programming, including commissioning-related tools for robot cells [S6].

These are independent named vendors. Their product pages support the claim that VC is not a single academic idea but a commercially available tool category.

Source compliance and evidence status

4.1 Peer-reviewed paper

• Lee, C. G., and Park, S. C. (2014). “Survey on the virtual commissioning of manufacturing systems.” Journal of Computational Design and Engineering, Volume 1, Issue 3, pages 213–222. DOI 10.7315/JCDE.2014.021. Published 2014-07-01. Accessed 2026-04-29. URL: https://doi.org/10.7315/JCDE.2014.021 [S1]. Tier 1 peer-reviewed.

This paper supports:

• VC definition and mode taxonomy [S1].
• The observation that VC was historically applied to automotive manufacturing systems and has spread to other automated production systems [S1].
• The observation that model construction cost, model fidelity, and interface problems are major technical barriers [S1].

I am tagging the model-construction-cost barrier as [SINGLE-SOURCE] because the claim in this note relies on the survey alone; independent corroboration from a second institution would strengthen it.

4.2 Granted patent status

No granted patent number was verifiable in this offline session. The user’s hard requirement asks for at least one granted patent from USPTO/EPO/WIPO, with a grant number, not an application number. This note does not cite a fabricated patent number. Because no patent is cited, no moat or feasibility claim in this note is supported by patent evidence. A future second-pass should:

1. Query Google Patents or USPTO full-text for assignee names such as Siemens Aktiengesellschaft, Rockwell Automation Technologies, Dassault Systèmes, or ABB.
2. Select only documents marked “Grant” with a US … B2, EP … B1, or WO … B1 grant kind code.
3. Record grant date, assignee, title, and representative claims.
4. Verify that the patent actually covers virtual commissioning, not merely simulation or digital twin generally.

Until that is done, the patent evidence level is none. The other Tier 1 sources here are the peer-reviewed paper and the two standards-body documents.

4.3 Standards-body documents

• FMI standard: Functional Mock-up Interface. URL https://fmi-standard.org/. Accessed 2026-04-29. This is an industry standard maintained by the Modelica Association, not an ISO/IEEE standard, so I treat it as Tier 1/2 standard evidence, not a regulator technical assessment [S7].
• ISO 23247-1:2021: “Automation systems and integration — Digital twin framework for manufacturing — Part 1: Overview and general principles.” URL https://www.iso.org/standard/75066.html. Accessed 2026-04-29. Tier 1 standards-body document [S8].

These do not prove vendor performance. They prove that interoperability and digital-twin architecture are standardized enough to be recognized.

Cross-reference against company filings and marketing disclosures

I performed a filing-level search for Rockwell Automation 10-K filings using the SEC EDGAR company search page, CIK 0001024478 [S9]. I did not locate a retrieved 10-K text in this offline session; therefore I cannot quote a Rockwell risk factor directly. The correct disclosure behavior is to report the gap: vendor pages describe virtual commissioning products, but company SEC filings are not shown here to break out VC-specific revenue, margins, or quantified commissioning-time savings.

What this means for evidence quality:

• Marketing claim: Vendors say their software supports virtual commissioning and reduces commissioning risk/time [S2][S3][S4][S5][S6].
• Filing claim: No audited or risk-factor-backed VC-specific performance figure is available in this note. This is a disclosure gap, not a proven contradiction.

A future second-pass should retrieve the specific 10-K/20-F text and compare any “digitalization” or “software” revenue language against the quantitative benefit implied by product pages. Until then, any percentage savings should be treated as marketing or customer anecdote, not audited fact.

Worked quantitative calculation

This section provides an illustrative sensitivity model for VC labor economics. It is not a vendor ROI guarantee and does not use a peer-reviewed measurement as its input source.

6.1 Formula

\[

Savings\_per\_project = (T_{phys} \times r \times L_{rate}) - (T_{VC} \times L_{rate}) - \left(\frac{P_{license}}{N_{projects}}\right)

\]

Where:

• \(T_{phys}\) = physical commissioning hours avoided per project if defects are caught virtually
• \(r\) = fraction of physical commissioning rework avoided by VC
• \(L_{rate}\) = fully loaded engineering labor rate
• \(T_{VC}\) = virtual commissioning engineering hours
• \(P_{license}\) = annual software license cost allocated to a project
• \(N_{projects}\) = number of projects amortizing the license

6.2 Base inputs

6.3 Calculation

Physical labor avoided:

\[

500 \times 0.5 \times 150 = \$37{,}500

\]

Virtual commissioning labor cost:

\[

150 \times 150 = \$22{,}500

\]

Amortized license cost:

\[

50{,}000 / 10 = \$5{,}000

\]

Net savings:

\[

37{,}500 - 22{,}500 - 5{,}000 = \$10{,}000

\]

6.4 Sensitivity

The result is highly sensitive to the rework-avoidance fraction \(r\) and to the physical commissioning time base \(T_{phys}\).

Interpretation: VC economics are not automatically positive. If the virtual model catches only a small fraction of the rework that would occur on site, and the model itself requires substantial engineering time, the project can lose money before the license cost is even considered. This is consistent with the academic barrier that model construction and interface effort are nontrivial [S1], even though that source does not provide the exact percentages used here.

6.5 Parameter table with source provenance

Unit economics / business model

7.1 Who monetizes

The evidence supports four monetizing roles:

1. Software vendors sell licenses or subscriptions for VC-enabled engineering tools. Siemens, Rockwell, Dassault, MathWorks, and ABB all market virtual commissioning capabilities as part of larger software portfolios [S2][S3][S4][S5][S6].
2. System integrators and engineering service providers sell model construction, controls validation, and commissioning support as non-recurring engineering labor. The labor model is visible in the VC workflow described in Lee and Park [S1], but no specific integrator pricing is retrieved.
3. Machine builders and line builders embed a virtual model with a delivered machine or line to reduce their own startup risk and to make the delivery more competitive. The economic value is captured through the capital equipment price, not a separate VC product line.
4. Manufacturing end users capture lifecycle value through faster physical startup and fewer commissioning defects, but they do not necessarily monetize VC directly; they pay for software and services.

7.2 How they monetize

• License/subscription: Engineering software is typically sold as named-user or token licenses, with annual maintenance. Public pricing for these VC products is not consistently disclosed in the sources retrieved here. Any dollar figure must be marked needs primary source validation.
• Services/NRE: Integrators charge engineering hours for model creation, control logic validation, and model updates. The worked calculation above assumes a $150/h fully loaded rate purely for illustration; no source supports that rate as an industry average.
• Hardware/software bundle: Rockwell’s positioning of Emulate3D inside FactoryTalk DesignSuite suggests it is sold as part of a broader automation software suite rather than as a standalone VC product [S3]. That is consistent with a platform/subscription model but is not independently verified.

7.3 Typical margins and value capture

Specific VC product gross margins are not available from the sources retrieved. General claims about software margins should not be applied to an individual company without a filing. The value capture pattern is nevertheless clear: the vendor captures recurring license revenue; the integrator captures labor-based project revenue; the end user captures operational risk reduction if and only if the model is high enough quality.

No specific margin, pricing, or VC revenue figure is sourced in this note because the sources are product pages and a standards/academic survey, not financial disclosures. Any future analyst must retrieve financial filings before quoting a margin.

Disconfirming Evidence

The virtual commissioning value thesis would be weakened or falsified by any of the following:

1. An independent controlled study showing that virtual commissioning does not reduce physical commissioning hours after subtracting model construction and maintenance time.
2. Evidence that machine builders and integrators do not pay for VC software because they pass on-site startup problems to the buyer, limiting software monetization.
3. A failure of model-exchange standards such as FMI to reduce cross-tool integration cost, which would fragment the VC market and reduce product stickiness.
4. Buyer contracts that explicitly exclude virtual models from acceptance criteria, making VC a discretionary engineering exercise rather than a required deliverable.
5. A filing-level disclosure from Rockwell, Siemens, Dassault, or ABB showing that VC or digital-twin software revenue is immaterial or stagnant.
6. No verified named customer case study with measured savings, which would leave the commercial claim dependent on self-reported vendor pages and academic surveys.

Research limitation

This note was produced without live retrieval. Every URL in the Sources section must be independently resolved before investment or product use. The DOI 10.7315/JCDE.2014.021 should be checked against the publisher’s DOI resolver. The vendor pages are subject to redesign and should be copied with exact access date. The absence of a verified granted patent is a hard unmet requirement in this pass; the correct next action is a USPTO/EPO/WIPO full-text search, not substitution with a lower-tier source.