A simulation can converge, produce a convincing colour contour and still lead an engineer to the wrong conclusion.

That is an uncomfortable fact in modern engineering.

Computational fluid dynamics can produce detailed pressure distributions. Structural analysis can predict stresses and deformation. A system simulation can show how a motor, controller and mechanical load respond to a command.

Each result may be mathematically consistent with the model.

But none of them, on its own, establishes that the physical system will behave the same way.

The question is not simply whether the simulation ran. It is whether the prediction is credible for the decision being made.

A Result Is Only as Good as Its Assumptions

Every engineering model is a deliberate simplification of reality.

A structural model may assume ideal contact between components. A CFD analysis may use estimated boundary conditions. A system model may represent mechanical friction with a simplified equation.

These assumptions are not necessarily mistakes. They make complex engineering problems solvable.

The difficulty begins when the assumptions disappear from the discussion and only the results remain.

Consider an electromechanical actuator.

A model might predict that a motor and gearbox can move a control surface through its required angular range. It may show acceptable response time and stable position control.

But what happens when the direction reverses?

Does the gearbox contain backlash? How much friction is present? Where is position measured — at the motor or the output shaft? How does the control system respond when an external load acts against the mechanism?

These are not minor implementation details. They can change the behaviour of the complete system.

In a recent internal engineering study at SIKKA Group, our team examined a reference electromechanical flight-control actuator model as the starting point for a specific hardware application.

The reference architecture provided a useful framework for understanding motor behaviour, control loops, mechanical transmission and external loading. But the study also identified what would need to change before the model could represent the intended hardware: motor characteristics, gear ratios and backlash, position feedback, control logic and operating loads.

The distinction matters. A reference model may describe the right class of system without yet describing the particular system being engineered.

A simulation becomes useful when engineers understand which assumptions matter, how sensitive the result is to them and where additional evidence is needed.

Verification and Validation Are Different Questions

The terms are often used interchangeably. They should not be.

Verification asks whether the model has been implemented and solved correctly.

Are the equations, units, connections, numerical methods and software implementation consistent with the intended mathematical model?

Validation asks whether the model represents the relevant physical behaviour sufficiently well for its intended use.

Does the prediction agree with appropriate experimental evidence, within an acceptable level of uncertainty?

The distinction is set out formally in ASME's verification and validation standards — V&V 10 for computational solid mechanics, and V&V 20 for computational fluid dynamics and heat transfer. Those standards address specific computational domains, but the same distinction is useful when judging system-level models.

VERIFICATION

“Are we solving the model correctly?”

Compared against
The intended mathematical model
Typical evidence
Consistent equations, units and connections; numerical convergence; agreement with analytical or reference solutions
Establishes
That the model is implemented and solved as intended

VALIDATION

“Does the model adequately represent relevant physical behaviour?”

Compared against
Relevant physical behaviour, for a defined intended use
Typical evidence
Comparison with appropriate measured data across the relevant operating conditions, with stated uncertainty
Establishes
How far the prediction can be trusted for the decision being made

A model can pass verification and still fail validation.

It may solve the equations perfectly while representing the wrong boundary conditions, missing an important physical effect or using parameters that do not reflect the hardware.

And validation is not a universal certificate of accuracy.

A model that agrees with measurements at one operating point may not be reliable across a wider range of speed, temperature, loading or operating conditions.

ASME V&V 20, for example, quantifies the agreement between simulation and experiment at a specified validation point, and leaves accuracy elsewhere — by interpolation or extrapolation — to engineering judgement.

A model must be judged against the question it is being used to answer.

Validation is also not the same as qualification.

Equipment qualification and acceptance testing establish whether a product meets its specified requirements — for example, environmental testing tailored from MIL-STD-810 or carried out to JSS 55555, as called up by the applicable contract, or a customer's own qualification and acceptance procedures.

Model validation assesses whether a computational prediction can be trusted for its intended use.

The two can support one another, but they are not interchangeable.

The Difficult Part Is Often at the Interfaces

Engineering disciplines rarely operate independently in a finished system.

A motor produces torque. A gearbox transmits it. A sensor measures motion. A controller reacts to the measurement. The output mechanism works against a changing load.

Each element can appear satisfactory when considered separately.

The assembled system introduces interactions.

Backlash can delay output movement after a reversal. Compliance can change the dynamic response. Friction may produce different behaviour at low speed. Sensor placement can influence what the controller believes the mechanism is doing.

The important question becomes whether the model captures the interactions that govern the system's actual performance.

This is why system-level modelling matters.

It is also why system-level modelling cannot eliminate the need for physical evidence.

What Should Engineers Compare?

A credible validation exercise starts before the test.

Engineers must decide what the model is expected to predict, which measurements will be taken and how agreement will be assessed.

For an electromechanical actuator, useful comparisons might include commanded versus measured position, response time, overshoot, motor current, reversal behaviour and response under external load.

A single successful movement tells us little about the full operating envelope.

Likewise, matching one experimental curve does not establish that every internal model parameter is correct.

The comparison should cover the conditions relevant to the engineering decision, with attention to measurement uncertainty and the sensitivity of the result to uncertain inputs.

The chart illustrates the idea of comparing a prediction with a measurement. All three curves are generated, synthetic data; they are not SIKKA test results, model outputs from any project or a performance claim.

When the prediction and measurement disagree, the difference is not simply a failure.

It is information.

It may reveal an incorrect parameter, an overlooked physical effect, an inadequate sensor model or a problem with the test setup itself.

The purpose is not to make every curve look identical. It is to understand the discrepancy and decide what it means.

Closing the Engineering Loop

The most useful relationship between simulation and testing is iterative.

A model helps engineers identify likely behaviour, investigate alternatives and determine what should be measured.

Testing reveals how the physical system responds.

The comparison then informs the next engineering decision: revise an assumption, improve the model, change a design, investigate an unexpected effect or gather better evidence.

Engineering confidence develops through evidence, comparison and iteration.

Sometimes the model is sufficiently accurate for the decision at hand. Sometimes it is not.

Both outcomes are valuable when they are understood.

At SIKKA Group, this relationship is particularly relevant to the connection between Software & Simulation, Equipment & Technology, and Projects & Services.

Digital engineering can help explore the behaviour of a proposed system. Physical engineering, integration and testing provide opportunities to examine those predictions against real constraints.

Our objective is to strengthen the connections between these activities — not to treat simulation as a substitute for engineering judgement or physical evidence.

Confidence Is Earned, Not Rendered

Better simulation tools allow engineers to investigate increasingly complex systems.

But more detailed models, finer meshes and more sophisticated visualisations do not automatically produce more trustworthy decisions.

That requires clearly stated assumptions, appropriate verification, relevant experimental evidence and an understanding of uncertainty.

A convincing image is not proof.

A converged solution is not necessarily a validated prediction.

Simulation helps us ask better questions. Validation helps us understand how much confidence to place in the answers.

Technical References

  • ASME V&V 10-2019 (reaffirmed 2025), Standard for Verification and Validation in Computational Solid Mechanics. American Society of Mechanical Engineers. ANSI Webstore
  • ASME V&V 20-2009, Standard for Verification and Validation in Computational Fluid Dynamics and Heat Transfer. American Society of Mechanical Engineers. ANSI Webstore
  • MIL-STD-810H (with Change Notice 1), Environmental Engineering Considerations and Laboratory Tests. US Department of Defense. DLA ASSIST QuickSearch
  • JSS 55555, Environmental Test Methods. Joint Services Specification, Directorate of Standardisation, Ministry of Defence, India — applicable edition as specified in the contract.