How Virtual Commissioning Works: A Walkthrough of the AutoIntel VC Playbook

Virtual commissioning (VC) is one of the most valuable tools in any manufacturer's toolkit. Who wouldn't want the ability to de-risk some of the most challenging aspects of launching a new production line or entire manufacturing system? To help guide manufacturers through the process and benefits of VC, we created a step-by-step playbook that demonstrates how our experienced team executes virtual commissioning.

In our newest audio blog, I decided to take the VC Playbook one step further by walking through it page-by-page. Hopefully, the added technical details and behind-the-scenes info I was able to add about our VC process will answer a lot of your questions about whether or not VC would be an asset for your next project. If you have any other questions or want to talk about engaging the AutoIntel team, please reach out to us at info@autointel.io.

Watch the video or read the transcript below -- and don't forget to download the free Virtual Commissioning Playbook here.

Virtual Commissioning Playbook Demo [ Transcript ]

[00:00:00]

Let's take a look together at our virtual commissioning playbook.

Let's start offwith what is virtual commissioning? So basically, virtual commissioning istesting an industrial automated system in a virtual world much the same way youwould before equipment ships to your site or when equipment shows up on siteand you want to test it before you begin production.

We just do the same things, or very similar things, in a virtual world. It all revolves around testing the control systems, so those are robot controllers, PLCs, HMIs, sometimes even MES or SCADA systems. So why should you use [00:01:00] virtual commissioning? Virtual commissioning is great for people who have very tight timelines for commissioning high-risk projects.

Maybe these are newer equipment systems or complex things you haven't done before. If your production time is very valuable to you, if being a day or a week late means that you're going to lose an exceptionally large amount of what would otherwise be productive time and, and revenue, virtual commissioning might be for you.

And maybe there's other ancillary things that go along with it, like maybe you have new site personnel, new people who need to be trained. Virtual commissioning is a great way to provide a comfortable atmosphere for new people to be trained on equipment virtually as opposed to doing it only in the real world.

But the big value play for virtual commissioning is getting things tested and [00:02:00] validated sooner reducing the amount of time on site, reducing the amount of surprises that typically occur when you're doing on-site debug and commissioning. So one of the big value pieces is reducing that cost for engineers, personnel, materials and otherwise productive time on site, get you up and going faster and cheaper.

Let’s talk a little bit about when you should do it. So one of the misconceptions with virtual commissioning is that it, to some people, appears as like a start and a stop process with the existing engineering processes, and that's not how it works. Virtual commissioning goes alongside the existing engineering process, and if anything, it should reduce the amount of time and energy required to engineer a system, not add to it.

That's a little bit about when you should do it. So typically we're going to be, you [00:03:00] know, towards the second half of a project, think 75% mechanical and electrical design review all the way through startup and commissioning at least for a site acceptance test. So that would be before the equipment ships, right around that power on timeline.

We're just going to hit some of the highlights here.

So we'll start with project definition. So when we give our clients proposals, some of the upfront things that we typically ask for or want to anticipate sometime during the virtual commissioning project are what's listed here. Mechanical drawings, again, these are typically 3D. This is gonna give us the equipment that's in scope, and that's typically an export from SolidWorks or Inventor.

We're comfortable working with just about any 3D modeling program. A lot of times we'll [00:04:00] take things in step files. We're comfortable working with just about what any major 3D mechanical system.Electrical schematics, so these are going to be things like wiring diagrams and controls layouts, controls bill of materials.

This allows us to know what devices we're gonna be working with what their tag structures are, where they're physically located in the system. And tag lists I somewhat alluded to there in the electrical schematics. This is gonna be a list of inputs and outputs for the robots, HMIs, PLCs. If they're available, we'll take preliminary PLC and HMI programs.

For us, getting information sooner rather than later is always a good thing. The more information we have, the sooner the better. This also applies if we're talking about distributed control systems.

So let's talk [00:05:00] about once we get kicked off, what does atypical virtual commissioning project look like? One of the first things that we like to do is start with the end in mind. So we've got here what we call our buy-off checklist, and one of the things that we prefer to do early on is think about what the success criteria is for this equipment that we're going to be virtually commissioning.

What are some of the tests that we want to run? What are the outcomes for those tests that wouldsignal that they pass or partially pass or fail? So we'll want to know what the criteria for success is for an FAT and in this case, a virtual FAT A lot of times these checklists can be very long.

That's okay. We've got ways where we can automate some of these tests so we don't have to step through each one of them. We can programmatically test them in kind of rapid succession automatically and evaluate them for their success after batches of [00:06:00] them are complete. A lot of times there's a wide breadth of things that you can test.

So we've got somethings we commonly do for just groups of things that we do here for virtual commissioning and we break it down a little bit further as well. Okay, let's talk about execution. So now is when we've got alignment, we're kicked off. We really break down our project execution into two phases, and this is an execution methodology that we've honed over several years and continue to improve on.

But the structure for us really matters. So the first phase is getting to a point where we can start testing a virtual system. Think about that as like the end of your power-on phase if you were doing, equipment in your facility or at your supplier's facility. So it's getting to the point where we could test.

And phase two [00:07:00] is doing everything, testing included, to get to a point where we pass our criteria for success and essentially that we do all the debugging testing and until we have satisfied all of the test cases and we think that the controls are complete. So let's start with phase one. So that's really starting from some of the deliverables we talked about a few minutes ago.

We create this test-ready virtual environment. Again, that's really the first place we start.Our first step in the process is creating a 3D kinematic model. So what is that? That's basically taking 3D CAD that we get from our clients and integrating in the moving parts and pieces so that we can, at some point in the future, map the controls that will move these mechanical elements around.

So that's going to be things like identifying and putting in servo motors, VFDs linear motors what have you. [00:08:00] All the moving parts and pieces, we want to make sure they have the right motion profiles they have the right speed profiles, acceleration, deceleration, max speed. We want to make sure that we have all the right moving parts and pieces, the right axes, the right equipment in, in a not as much of a smart environment yet.

We're just getting all of the moving parts and pieces in first so that when we come back in later and try and control them with our inputs and outputs, they do so properly. The next step for us is device and tag mapping. Think about this as plumbing a new house. So this may be before we have PLC, HMI, SCADA, DCS programs.

But basically what we're doing here is we are mapping the inputs and the outputs to this 3D kinematic model for information we're going to send and receive from these controllers at some point in the future. We don't necessarily need those controllers yet. [00:09:00] What we're doing is moving first to get everything mapped properly so that when we do get those controllers we're able to move efficiently once we have them.

Part of the reason why we do this is one of the most critical steps in our process, and I would say more often than not in virtual commissioning, we get squeezed by the project schedule. If the equipment has to be commissioned on a certain time, that milestone rarely moves. And so if there's delays earlier in the project that propagate later, controls, debug, and testing typically get squeezed.

So that is the critical time for us. When we get PLC code that is about 90% complete for the first time our kind of mission-critical step is to take that 90% and get it to100 as fast as we can. And so everything really [00:10:00]revolves around that, those two points in time. All right, so now that we've got the tags mapped, we've got our devices in now is when we receive our controller code for the first time, and we start mapping the inputs and the outputs.

Now, a lot of times, there's going to be many errors we have to work through in order to get it to just run in a happy path or an auto-run state. So that's really where our team is going to start. There, there may be, copy-paste errors in the code.There might be code missing, things people forgot about.

Any number of things. Faults that aren't mapped correctly, faults that are missing. Our first step, once we do receive controllers for the first time, is just getting it to run in a steady state. We're not worried yet about going through all of the different test cases and ways that we can perturb the system.

We just want it to run naturally [00:11:00] in a happy path first and then go from there. Once we do that the next step for us, which a lot of times can happen in parallel is enabling test scenarios. So what does this mean? Earlier on, we talked about what the success criteria was and what some of the tests that we wanted to do were.

Maybe some of these tests are ones where we need to create some logic or some manual steps for us to be able to test certain things. So let's say, for example, you have a series of robots and you want to test what happens if we lose pneumatic pressure to these robots. How will they fault? How can they recover?

Can they recover?So obviously, we're not going to have compressed air in our virtual world, but we will have a way to map those tags and create that scenario. So that's an example of something we can enable as a test scenario. Other things that we typically enable are pressing buttons.

What happens if somebody hits an [00:12:00] E-stop? What happens if we create a jam? What happens if raw materials aren't replenished the right way? All of these things are tests that we need to enable and we typically do that before we hand over the environment to the controls engineers.

Speaking of which, what's our next step in phase one? Typically that's deploying it to the cloud.What does that mean? What we found is that when we create this environment, we've got things moving virtually as they would in the real world, and we're ready to start more thorough debug and testing.

Again, think about it as you would on site where you run through your tests, you make sure that the equipment's ready to go. We're doing that virtually. We developed this environment for that testing, and we hand it over to the people who are responsible for developing that [00:13:00]those controls programs.

So we deploy it to our cloud. That means that somebody who we give specific access to in a secured environment will be able to log into it. They'll have access to their controllers. They'll have access to the virtual environment. We have a way that you can see here at the bottom kind of a- proprietary network way that we get everything to talk to each other and we enable our clients to get up and going quickly.

Again, the name of the game here is speed. We want them to come in without having us looking over their shoulder, without having them have to install software, get licenses, and spend a bunch of time getting to the point. We want to go straight to the point. It also enables us to not have to email back and forth new controller programs, new environment files.

It's a single source of truth, and it saves a lot of time, and our clients love it. So this again is we're [00:14:00] at the end of phase one. We're pushing it to our clients. A lot of times they want us to take an active role, and we're happy to do that. We're gonna talk about it in just a minute, but it's not just lobbing it over a fence, and many times it's giving access directly to the people who need it.

All right, phase two. So we've got the virtual environment. We've got it to a happy path. We're able to get parts in and out, and we're able to get from front to back of the process, but now we need to really go through the nitty-gritty details of the test and make sure everything works the way that it's supposed to.

That's what this testing and debug phase is all about, and that's where we start with phase two.In fact, that's pretty much most of phase two. If our team takes a hands-on approach, which we do often our team is going to be taking the test cases we identified early on in the project again, automating those to the extent possible.

But in any event, we're going to be going through those independently as an outside [00:15:00] auditor and identifying and tracking issues for the controls engineer. So why do we do that? It takes the lift off of the people who probably have a lot on their plate at this point in the project, right?

They're going to be the people who are trying to get these controls programs, PLCs, robots,HMIs, DCS, SCADA, MES in some cases, from 90% to 100%. Sometimes, and it's more often than not, they find it our clients find it easier if we find the issues and tell them what those issues are. We don't take responsibility for fixing the code.

It's their code, it's their intellectual property. But what we want to do is put them in a checklist form that they can go through see what kind of issues that we found and remedy them rather than having us go through them one by one over Zoom or something like that. So it's an easy way for them to use our deliverables.

So this period of time is for development, [00:16:00] testing, and debug. This is that iterative time that people normally would do that on the plant floor. This is where we're getting the value out of our services. This is doing things that you were going to do later, sooner while you're in the office in a more comfortable spot.

You're able to go through these tests in rapid succession. You're not creating a huge mess if there's a catastrophic issue. And so this iterative process continues until we meet the criteria of success. We're able to pass all of our tests, and typically at that point in time, we will memorialize that moment through what we call a virtual buy-off.

And a virtual buy-off for us is similar to what a buy-off is in person. You bring the people who created the systems or equipment, the integrators the eventual consumers the end users eventually, and you demonstrate that the system works and how it works. A lot of times [00:17:00] we won't go through all of the tests there together.

Our team typically records those so that people can preview them ahead of this virtual buy-off.But the consumer of these systems, a lot of times will want to run it through the paces. Maybe pick a few different tests to run maybe throw things out there that were not on the buy-off checklist or considered before.

We welcome that.But in any event this virtual buy-off is something we typically record and invite people to whether you're the buyer, the seller, the integrator, andagain, it's a point in time where we can basically show that our controls are ready for the field. And then lastly one of the things that we love for our clients to do is to continue to use the things that we've developed.

If you think about it, when we just finished our virtual buy-off, we have a virtual replica [00:18:00] of this industrial automated system, and we hate for these kind of things to go on a shelf. So what are some of the things that our clients can do with it? They can keep it and maintain it. We can keep it and maintain it for them.

If future design changes come, think a different automotive year vehicle or a different packaging type for a consumer products company, they may wish to test these systems in a CI/CD-type fashion rather than doing their own continuous improvement on the live equipment. We can help with that.

I talked about training a little bit earlier. We can help with that. So we want to keep these digital assets fresh, available operational, and we have a number of ways that we can do that. I'll end with just some of the things that we commonly find for resistance to change. Sometimes not always, but [00:19:00]we, have some reluctance some people who maybe aren't familiar with this, haven't done it before, and need some help to see the light, so to speak.

So one of the things that I mentioned earlier is that the critical time period for virtual commissioning is getting control code for the first time to buy-off. That everything in our process revolves around speed from point A to point B here.If there's controls delays that closes that gap and it makes it very difficult for us to be successful.

So if and when there are those delays, you just have to know that's a risk in the project and it's something that we wish to stay ahead of as best we can. Late design changes. Sometimes these are a good thing, right? We find things that need to be fixed, maybe catastrophic issues.

That happens from time to time. But one of the things that we need to stay ahead of [00:20:00] is making sure that what designs and deliverables we've been given are the most up-to-date. In other words, we would hate to get to the end of the project and realize that there were changes to what we've been working on that weren't communicated to us, so we want to stay in the loop there.

And then some other things that we find for resistance to change. Again, people find it difficult to imagine that the code that we're dealing with the inputs and outputs and devices are so robust and they are so digitally accurate that it actually is the same representative system as far as the controllers go.

Your control systems think they're controlling the real equipment when really they're controlling a virtual replica of that. Some people have a really tough time digesting that. They think what we do is more of an art project than a science project, and that could not be any further from the truth.

So that's a little bit about our virtual commissioning [00:21:00] process. I hope this was helpful. If you have any questions, feel free to drop us a line at info@autointel.io, and we'll see you in the next one.