Simulation vs. reality: Can AI and virtual testing replace old-school engineers?

How to balance high-fidelity simulation with human skepticism
Feb. 24, 2026
6 min read

Key Highlights

  • While AI and simulation are invaluable for catching logic errors early and reducing commissioning time, they cannot account for the harshness of the real world, such as sensor noise, mechanical wear and physical tolerances.
  • Advanced tools can calculate technical values with ease, but they lack the seasoned judgment of a veteran engineer who can question logic and identify when a system is being oversized or improperly designed.
  • Effective testing requires a high-fidelity approach where customers and operators are encouraged to break the simulation to expose the gaps between programmed code and actual machine behavior.

Engineers ponder applications of artificial intelligence (AI). For instance, one may ask an AI to calculate the kVAs for a 60-A 208-V load off a 480-input transformer. That type of computation could inspire noises like those made by Henry’s assistant, Mac, when he meets Rosey, the Jetsons’ robotic maid for the first time.

Using the formula below, the answer for a 60-A load on a 480-V/208-V transformer would be 21.6 kVA.

That is nifty. Why do we need chief engineers with 45 years of experience any longer? Just kidding. They will tell you why you are oversizing that transformer and check your logic and not just your math.

ChatGPT will not do that. I often wonder if it is possible to add personality to the AI, and I found that it is possible to ask it to spit out facts without conjecture. I found that its programmer was a “mansplainer.”

It all reminds me of the fictional character Skippy in Craig Alanson’s Expeditionary Force series. Skippy is a sentient artificial intelligence, but also the name of the author’s favorite peanut butter brand. This is probably not by coincidence. Skippy reminds me that AIs have a place, but are also not infallible.

Skippy’s point of view is like when a project engineer defines rolls on a project charter. The responses I get as a project manager when asking engineers to tell me what they think their roles are in an automation project are often similar to Skippy quotes.

  • On human competence: "Striving for competence."
  • On disrespect: "Don't call me that. It sounds disrespectful, monkey."
  • On situational awareness: "Mistakes were made.”
  • On his role: "I am not a flying monkey."

Skippy refers to humans as monkeys and meat sacks. Skippy manifests as a beer can. Craig Alanson’s main character is Colonel Joe Bishop, who steals a starship and fights aliens, along with his best pal, the beercan AI named Skippy.

This could correlate to line engineers and off-duty activities in automation. What is the point to my nontraditional drivel here?

Artificial intelligence is a sidestep from simulation. Simulation is becoming more prominent in our automation world as a solution to checking out I/O and creating or recreating systems and as a means of testing.

Get your subscription to Control Design’s daily newsletter.

Imagin that you can take all the historian data you want and correlate it to a standalone system that then can be inputted to make your PLC code respond to real-world scenarios. However, it’s all done in a box and with an attached FactoryTalk View Site Edition (SE) or Ignition screen, and no one knows that behind the scenes is not a plant. If it were Skippy doing the simulation, then he would claim to be amazing and tell me to be grateful.

I am skeptical. Call me Old School, as I have reached that age, and I still have not conformed to accepting that I am not the smartest person in the room, though this is not reality. I have found that artificial intelligence seems to forget humans can be two things at once: grateful and skeptical. Let us break it down.

When using simulation for testing PLC code, it is possible to catch logic errors early, make development faster and reduce commissioning time. Sequences, interlocks, permissives and state machines may be validated before the hardware exists. Functional debugging of motion, batching and safety-related logic is testable at the functional level. Development is quick because more than one person can be on the machine at the same time. Downtime is a non-factor.

Skippy would say, “Load it,” on commissioning day because 80% of the bugs may be worked out and because he works in light years, not human time. Safety testing is good because fault scenarios may be tested without the possibility of harm to machine or to human.

That sounds great thus far. “What is the problem?” you ask.

Simulation fidelity is never perfect. If the same integrator programs the simulator as the PLC code, then there is not an independence that should be required for testing. Also, simulation does not involve inertia, real-world timing, sensor noise, network problems and machine tolerances or little things like hydraulic oil quality. Bouncing sensors, slow valves, sticky actuators and human mistakes often show up in operations on the plant floor.

The reality is that simulation is a baseline for functional code, but not for a functional machine. There is a chance that errors will be hidden in simulation that will come out in the field related to integration of drives, networks, safety devices and vendor-specific quirks.

The high effort of coding required to create a simulator does not account for scan time, jitter and asynchronous tasks. If the model is too simple, then the result is not a good value for the time it took to simulate. Also, if the model is made without machine knowledge, then it will not be akin to the real world.

Did you know that F-22 Raptor pilots and F-35 Lightning II pilots only do simulation training before their first solo in those 5th-generation planes? How are they successful? The Air Force chooses only top graduates of the Undergraduate Pilot Training (UPT), which includes an introduction to fighter fundamentals. They do a full simulator transition course. Academics, emergency procedures and systems checks are done without risk in the simulation environment. Dozens to hundreds of hours are spent in high-fidelity simulators, and then their first solo is as controlled as it can be.

In short, the Air Force reduces the risk before the pilot is seated in the F-22 or F-35 seat. They also do not go up alone. The instructor is on their wing and radio. However, the Air Force does not publicize success rates. They publicize the training pipeline and the requirements to get to be an F-22 or F-35 pilot. At this point, Skippy would tell me to get to the point.

Skippy, as an AI, can do millions of simulated scenarios and gather the data in his fictional world to run a $100 million industrial machine through its paces. An integrator in the real world of automation will only be as good as the data they have and the time they put into the simulator. A top-gun simulator in the Air Force is a difference in granularity than what the average control system integrator is doing for machine simulation.

Thus, if an integrator is going to use simulation at a factory acceptance test (FAT) to show the customer what their code is capable of, then the customer should be able to see what the inputs are and what the scenarios are based on, and there should be an understanding of how the code on the simulator was programmed and the intent.

If it is truly a simulation of the machine, then bring an operator to FAT. Allow that same operator who breaks your machine to break that simulator. Understand too that a new machine is not the same as brownfield conversions and that, even with simulation, the real world will be harsher than any artificially made-up scenario. Deciding the requirements of simulation may determine if it’s more science-based than art-based. Even Craig Alanson made his AI into things he relates to: peanut butter and beer.

About the Author

Tobey Strauch

Arconic Davenport

Tobey Strauch is currently managing brownfield installations for controls upgrades at Arconic Davenport.  She has previously worked as principal controls engineer and before getting her bachelor’s in electrical engineering, was a telecommunications network technician.  She has 20 plus years in automation and controls.  She has commissioned systems, programmed PLCs and robots, and SCADAs, as well as managed maintenance crews.  She has a broad mix of mechatronics with process control.  She enjoys solving problems with Matlab and Simscape.  Contact her at [email protected].

Sign up for our eNewsletters
Get the latest news and updates