Hi, my name is Tyler Phillips. I'm the global business development manager
for digital Design at Rockwell Automation.
With me today is Antoon Laane, one of our product managers who covers digital
engineering, with whom I work closely together.
We want to talk to you today about digital engineering transformation.
Our agenda will be brief. We will cover an introduction of ourselves.
We're going to talk about how digital engineering is evolving and how we can evolve
the design to a digital world.
We'll walk through how those projects take place, and then we'll summarize for you.
Let me tell you a little bit about myself. My name is Tyler Phillips.
As I said, I'm the global business development manager for digital design.
I've been with Emulate3D and or Rockwell for about 11 years.
Emulate 3D became a part of Rockwell in 2019, and before that I've been with Emulate3D
since 2012.
I've spent most of my career over the last 30 years in simulation for industrial
applications, mostly manufacturing and material handling.
I love, emulate3D and happy to be talking to you today.
And my name is Antoon Laane. I started at Rockwell back in 1986 and did a
lot of work in starting up designing and developing software and commissioning
systems.
And over the years I've done a lot of work as managing the pre-sales team, doing product
marketing and did a lot of work around Logix and Studio 5000.
And in 2018 I got engaged with the Emulate3D team.
We completed the acquisition in 2019 and I'm currently working on helping to integrate the
product into our organization and help evangelize the benefits.
So that's what we'll talk about today. So let's talk a little bit.
Antoon and I have worked together for a few years now and I think we've become pretty
good at doing a joint presentation.
So we're going to switch back and forth through some of the areas of this.
let's talk a little bit about digital engineering.
You know, traditionally projects as they've been done, have occurred a certain way, and
we want to talk about moving away from that, moving away from the kind of what let's call
the old way of engineering systems.
So let me ask you a couple of questions here. What if you could test and improve your
designs before you ever began production? What would that mean for you?
Have you had unpredictability in your commissioning phase that lengthened projects
that change your time to market, that delay the deployment of systems or that cause you
pain or cost with your customer or your partners and do you wish you had more
flexibility and confidence during the production process? Those are the things
we're going to talk about.
How can we improve those questions? If you answered yes to any or all of them?
So what is virtual commissioning? Well, you probably heard the term.
You probably have heard some other terms related to it.
But for us, what we're going to talk about today, virtual commissioning means using a
dynamic digital twin of a machine or a system which could be a combination of different
types of equipment and machines to test and debug the control system in a high fidelity,
realistic operating environment.
It's really not intended to validate real time signal responses, you know, with a very
small degree of response times.
But meant to give us a system that is, I'll say good enough and I'll talk about that in
just a minute, good enough to allow us to actually test the systems before they exist.
When we build a virtual commissioning model or model, we're really bringing together
three truths about automation systems, is the way we like to think about it.
We're bringing the mechanical truth, and that's usually CAD.
We're bringing together logical truth, which is the control system and electrical design,
and we're bringing what we would call the transient elements for the sake of Emulate3D,
the software we're going to talk about a little bit.
Those are the loads, the products, right? The baggage, the car bodies, the things that
move around the system that are handled by the equipment that are made that are taken
apart.
There's really a fourth one. And that's the thing, maybe causes the most problem, the
wetware, right?
The operators, the thing that maybe have the most variability. So actually there's
probably four we're bringing together.
But when we bring those three truths together, it allows us to do things
digitally. If we can do that in these digital environments.
So one thing that's important to remember, there's an old saying that's used in
statistics and it's moved into many areas of engineering and in industry, and that's that
all models are wrong.
But some are useful. And what we want to do with our digital
engineering technology at Rockwell is make useful models, right?
And when we talk about digital twins, we may not be talking about a single model or just a
twin.
We may be talking about digital triplets. We may be talking about models of the same
system that look at different areas or have different granularity.
So it's important to know that when we're building digital twins, we're focusing on
those areas that need to be most right or highest fidelity in order to test the things
that we need to test. Yeah.
So what I'm going to do is I'm going to take a step back and look through how we work
through a digital engineering project. Right?
Why are we doing this? If I look back at how I started myself, when
we did our projects, design decisions were made really early on and they were based on
estimates we made and histories of how we had done it in the past.
And we were relying on ourselves being good about redesigning things or redeploying
things to have success in the project. Right.
When we did our system design or in my case, the automation design and the build and test
we needed to do everything off of theoretical thoughts about how the system would work.
We could test small bits of code, but the majority of application code needed to be
tested late in the project, which of course made that late testing a high risk event and
I'll admit I've had projects where I did not anticipate everything correct, and we found
problems really late during the development cycle.
The other thing is that when we tested the application, we needed physical parts to move
through the system and we had very poor linkage between our mechanical engineers, who
designed the machines, and us as automation engineers, who developed the software we
relied on the mechanical design being a given.
We had no back and forth between the mechanical engineers and the automation
engineers, right?
So they were typically the ones in charge, and automation just needed to make it work.
What that results in is when you're actually doing your commissioning and your startup,
you find things late and on site.
Pressures are high and there's a lot of people waiting for you to complete your bit.
The physical machine is there. Why isn't it running yet?
Well, it's the first time I can actually run my software so there's tremendous pressure on
completing your software development.
Instead of being flexible and when you find a problem saying, “I'm going to take a step
back and see how you can tackle it better”, the focus is on how do I get this done right
now with all those people breathing down my neck.
The other thing about these systems, of course, was that it if they were late, there
was pressure on lost productivity and when you were training, you needed to feed
products into the system.
Typically you needed specialists to help train the operators.
So there was time involved. There was travel involved, and it only happened for the set of
operators currently available.
So the customer had to supply his operators, all that good stuff.
And then when there were upgrades or changes, that whole cycle would start again.
It's really difficult to prove in advance that a change will actually improve a system.
So you need to test it. And I've actually been at customers who had
11 identical production lines, but because of the change in demand, one of those lines was
continuously used for testing new SKUs and making process changes before they deployed
them to the other ten lines.
But that meant that line was not producing stuff and they are expensive lines.
You don't want to have that high cost of needing production equipment to validate
things. You'd rather have that line produced 90% of the time and only do the final
commissioning validation to make sure everything is correct, after you developed it
on a digital twin.
So that's what this is all about.
We want to move to a much more collaborative environment where mechanical engineering and
electrical engineering can work together, where we can experiment with a model and
where it can show the mechanical engineers what they're doing.
Often when you're developing these applications, you have not one software
developer, but 5 or 6.
They all need to coordinate their work and see how they impact the model.
And each other. And you want to find opportunities for
improving the design. digital models are fantastic for doing that.
Then there's a lot of partnering involved, right? You're not doing this on your own.
You're working with all the related teams. Be that the mechanical design, be that the
operators, be that quality assurance.
All those teams work and third parties as well.
They all work together in this in this scenario.
Earlier we looked at a sequential flow.
And what we've really gotten to is a much more parallel work flow.
Concept and proposal are always in sequence. Absolutely.
But then that is followed by system design, and mechanical engineers need a certain time
to fine tune the model, but they can go and provide their design early on to the
automation engineers.
I'd say 30% into their system design cycle, they can already hand over a basic concept
and automation can start thinking about how will we develop this application code rather
than waiting for the mechanical engineer to finish all his work and then be giving a
final set of drawings. When you get a current copy, you start doing the markup and you
become productive immediately.
And that will also allow you to then start your controls development and eventually
controls testing against a preliminary model. As the system design evolves, it becomes easy
to process those updates into the automation design and you take advantage of lessons
learned and take advantage of fine-tuned things without having to repeat that detailed
mode markup in development.
You may fine tune it based on new things, but all your existing markup can stay, so you
work much, much faster in the product life cycle.
And yeah, when we really share that data early then we can go and do key parts of our
control testing. Control testing against physical equipment requires everything happen
real time and everything be finished before you can really test it.
We want to get to a situation where we can do at least partial testing much, much earlier
in the life cycle and we'll talk about that more later in this presentation.
Operator training, same thing. We want to be able to work inside the model
against the expected production demands and then use that to train the operators earlier
and to pre-commission the line, eventually having a final commissioning much, much
earlier in the in the cycle.
We see that a lot in FDA applications where validated testing always needs to happen on
the real world.
But all the pre-validation can happen against the digital twin and make sure that when
you're doing your final FDA thing you're much closer to a complete system so you don't have
to go back and repeat all your testing.
Last but not least you run into operation and maintenance.
After you have built your line, you keep your twin alive and use it for any and all
improvements prior to trying to roll those out into your factory or on your system.
Now we talked about taking all these items that are traditionally been on a critical
path and getting them stacked up in parallel so that we can make our process much more
efficient.
Let's talk a little bit about what we can do with concepts and proposals.
One of the one of the many things that emulate 3D allows us to do is really create
what we would call smarter proposals. That does a couple things.
It allows us to make smarter decisions by being able to see and understand the systems
better.
It's always amazing to me how even after working for many years in this industry, how
getting a team of people together who are all working on different parts of a system that
might be proposals, it might be drawings, it might be controls, it might be the sales guy,
it might be the customer and the vendor.
Using emulate 3D really allows us to rapidly create systems visually so that people can
make concept decisions faster, can convey the way the system works, what it looks like, how
it functions, and also increase understanding among that team.
We can take that system very early on and can begin to experiment with the concept.
We take systems and build them and then do batch runs of experiments to look at things
like throughput time and state utilization and make very informed decisions about
whether this system will meet the needs.
I'm always reminded of a customer who was able to do this and really had a strong
impact on the design of the system that they thought was going to work perfectly.
After analyzing it over a long period of time with demand, the vendor realized they had
some problems and were able to change that so that the vendor and the customer were in
alignment and everything worked well.
That ability to build the system concept and experiment with it is quite powerful.
Then we move on, of course, to the next stage, which is where we get into the into
the system design itself and, and here we, you know, we want to be able to reduce
certainly the mechanical design cycles and even the software cycles and get much, much
earlier feedback on approaches and make.
Decisions that could affect our application. Right.
If we look at virtual controls testing, we can start first validating that the layout is
right.
We can then do a process simulation of the assets and then we can take that model and
hook it up against a real control system and a human machine interface. that provides much
more detailed insight on what can we do controls wise with the system.
Eventually, we want to get to a point where we can do full virtual control testing, where
we not only look at the behavior of the the controller or the PLC in the middle of the
loop, but also all the smart devices.
When you think of it, each and every one of the modules or sensors or drives or
actuators, they all have their own local, local smarts these days.
Each of those “things” is programmed and configured and plays a role in this large
distributed control system.
So the PLC code is important? Absolutely!
It does the machine sequencing, but the details of the application control execute
throughout all those different smart devices that you have in your factory.
and we need to test that entire system, not just the logic flow.
And for that, we need we need high fidelity emulation / Device Echo.
And if we look at how do we bring that that system behavior into the system, the
environment we have typically starts off by loading a bunch of CAD data and bring that
into our modeling environment.
And then we will develop the application code against that, right?
We'll start to animate those individual elements in that drawing to make it move as
if it were a real machine.
We have toolbars for CAD operators to help us mark up the CAD and actually reflect the 3D
behavior for that.
And we have those for a few of the most popular CAD packages.
There's PTC Creo, which actually has three slightly different versions.
There's AutoCAD inventor and there's SolidWorks.
and then of course there's PTC Onshape, which is a full online environment.
I'll show you quickly what that looks like. In Creo, we actually have a toolbar that has
the same functions that we provide to you within the Emulate3D environment, but it
allows the mechanical engineer to apply the markup her/himself.
And (s)he's doing it in an environment that's comfortable for them.
You see here that the dialog, the way the windows come up is very, very different in
Creo than it is in SolidWorks or Inventor or in fact inside 3D itself.
The mechanical engineer here, in his own environment, is doing the markup and know
that the example is very simple.
But the point is he's just marked up a crank. We have exported that crank to emulate 3D.
We don't need to make any changes and we can bring that mechanical behavior and visualize
it and control it inside Emulate3D.
So that is the basic workflow.
yes, we have a toolbar in Emulate3D where you can do that.
Many people use it. Most of our examples are built around that.
But the person typically best suited to do the markup is the mechanical engineer and he
wants to do it in his space and have his tools, because he knows what he was thinking
when he designed that machine.
That's why that is where we start.
And I showed earlier, there is data from us. Yeah, we have here this machine.
It has a a fork transfer. It allows you to pick up a vehicle off of an
AGV. But the AGV itself, as well as the car body
we're going to look at, are supplied by others.
So we don't need to update that CAD over time.
That is typically an externally developed thing.
And here we look at it, we see our fork lift up the car body and then we see the AGV move
on and something else will happen in this in this process.
It's important for us that that we can evolve the design of our forklift, but we don't need
to worry about the design of the AGV, or for that matter, the design of the car body.
So any CAD file that we can import is fine for those functions.
Then when we get to a little bit further on, we continue to focus more on the controls
testing.
And you will see here the system where we are actually linking a model in the top left
where we are seeing a robot doing an assembly process.
We have the Echo PLC executing the logic code for the controller that's actually
programmed.
The application is running on the bottom. So that's a piece of Logic's designer.
And then on the right center of the screen, we see the tag browser for Emulate3D.
It creates the connection between the controller and the model.
So the model knows its inputs for how to respond.
In the top right you see Factory Talk Logix Echo, which is the controller emulator.
So we have a soft controller, a soft model and real-world code, and we bring all those
together to develop our application code.
And typically what will happen is that one engineer will build the Emulate3D model, but
then there could be 4, 5 or 6 PLC developers developing their own piece of the overall
application.
I mentioned earlier already quickly that Factory Talk logix Echo is the emulator for
this system.
So it is meant to make it easier to test your code in an offline or if you will, a
desktop-based controller emulator.
We don't need the physical hardware present.
we can support guard logix, compact guard logix and we can have those behave exactly
the way they do in the real hardware.
And with that we also have an API that allows us to connect to 3D or to other digital twin
models or even model based control type type applications.
So controller emulation is really a core part in achieving this digital transformation
and it's an integral part that we can test against hardware in the loop, but we find
that 90% of our customers prefer to work against an emulated controller.
This is also something that enables you to use this in the cloud. So many, many reasons
for doing this.
I mentioned here that CompactGuardlogix is supported.
That is a feature that's being added in November of this year.
The key parts that we focused on with Echo is we're able to apply the exact same project to
the physical controller or the emulated controller and we maintain the tree.
Of course we support the entire instruction set and we can do that connection to the
digital twin, very solid to test the real world logic flow, fault handling, etcetera in
in the system
Thanks Antoon. That's it. What you can do with the software
is really amazing.
I mean even though these are things that we talk about every day, when I can sit and hear
somebody else explain it and go through it, it gets me really excited and I'm being
really genuine here, actually.
So now we've got the mechanical model taken care of. We've got the logical design taken
care of.
We can even do an electrical model. Let's just show you briefly how we do that inside
emulate 3D.
We have a wiring diagram catalog, I guess you could call it a wire diagram, a wiring
diagram function. So I can actually establish all my functional connections, all my control
panels and verify and test them inside, emulate 3D.
We've got a little video we're going to run. We can navigate through the layers of the
electrical components and we can start to look at specific areas of the model to make
sure all those connections are there.
We can see that they're firing when we run that model and we can move in on very
specific areas because these are all going to be actual, you know, again, high fidelity
models of what's going on inside, not only the mechanical system, which we've already
done and the logical system, but also the electrical system.
One of the things that we're working on, it's not something that is yet released, but we're
working on also integrations with major other applications that do electrical layout and
electrical design for industrial applications.
So we look forward to over the coming year or so being able to release those and we have
some available to select customers that are testing those.
So we're really able to look at this in a way that we're able to force value changes and
make sure all these things are working correctly. It's a pretty, pretty cool
additional feature within Emulate 3D.
And then of course we can also interface with robots. Anton talked about how we can have
PLCs connected to the model, or we can have PLC emulators like Logic's connected to the
model.
We can also connect to a variety of robot programing tools. We made some a decision
many years ago actually in the development of Emulate 3D that we don't want to be an OLP.
We don't want to be the expert in robotics, although emulate 3D, has very robust robotic
modeling for simulation purposes with a lot of different generic and vendor specific
robots and some good robot solving tools we can actually connect to, for example, a robot
studio.
Fanuc Robot Guide Yaskawa Motoman. And even as you perhaps know, we acquired a company
called Clearpath Robotics, and they have a tool for their auto robots and we can connect
to those as well, which allows them the model to, in a very accurate way, emulate the way
the robot is working, right?
So not just a simulated way, but the way it's been programed. And that is a very powerful
tool as well.
And that can be done in conjunction with the other emulation.
You're doing so emulate 3D models do not have to be, let's say, sole source, right?
You don't have to be just running a model against a PLC or just running a simulation
model or just running a model against a robot controller.
But in fact, you can have all those things occurring at the same time.
So you have all these sources actually inputting into the model to make it a very
high fidelity model.
And that's really the goal we're moving towards, right, is that these models become
high fidelity input locations for a variety of sources of CAD of control, of robot
programing of a test environment.
And we'll talk about that here pretty quickly about the vision of how we do that. Yeah.
And of course, in a when you're controlling a robot, when you're programing a robot, the
moves are important. But all the interlocks, all the interaction with the rest of the
system is really where where the, the developers tumble. Right.
It's where and how do my my interlocks happen between what the robot is doing what the PLC
is doing, what the sensors tell me you you see how what happens when my path is wrong.
You don't detect that if you're offline.
But when you have product actually moving in the system, that becomes suddenly a lot more
visible. And robot programs on their own. The programmers typically do not have that
product movement as part of their their offline programing environment. Right?
So yeah, yeah.
And so that takes us to, to a next topic and that is in addition to, to robotics. Another
thing that a lot of our customers use is at least some basic fluid flows in their, in
their facility is we're not talking about oil refining type applications but a typical
consumer products company has liquids that they convert into chocolate bars or into
whatever else, shampoos, etcetera.
The process is fairly simple, but the handling of the product before and after is
is very important. And so what we have done is we put in a control for some hybrid
process flows. We we like to call it tanks and pipes and pumps and valves and all the
related stuff.
And that allows us to to route controller and fluid sources. We have pipes, we have mixers
and valves, mixed proof valves for for when you're trying to do clean in place different
pump types, sensors, flow meters, filling, filling tools.
And what we've done more recently is we've added, especially in a fault framework that
allows us to introduce different faults in the system because programing and application
is is important for the basic logic flow.
But in the end of, of a, of a project at about 20% of the code is focused on
sequencing the application the correct way and about 80% of the code is focused on how
do I deal with various faults.
So that's what the fault generation here is, is targeted at.
I can create all kinds of different faults in my system that I can then monitor and, and
log and see do I handle them correctly.
Another thing that we've been asked for is to give a little more capability on the liquid
properties so so we can emulate basics for for temperature, for conductivity, things
like that.
And we do lots and lots of collecting of of different data on those systems. And we've
also created a black box.
You've seen a black box earlier on the simulation side and you don't really care
about the physics interaction and you can go and do a simple mathematical model for for
those functions.
It doesn't have to be a physics collision thing, right?
So same thing for for a lot of the the processing, if you have a particular heating
curve or something you want to follow, you can put that in the system and there we see
one coming through right now.
And we can also create different scenarios and create all kinds of procedures that we
run based on on how the model behaves and where that takes us. In the end, our long
term objective is to allow you to do continuous integration of your logic
programing or your controls.
Testing into your overall control system development. So we you guys may be familiar.
In fact it unfold. That is where we can store projects with different versions.
We can do project analysis to look at the code quality. We can do file type
conversions. We can help people move projects from older versions to newer versions and and
actually view them and take a look at what they are. They end up in a version control
system, but then they need to be tested and three D is is an application that allows us
to do the model that we've just looked at.
So the emulation of this system behavior, it also has tools for data exchange to
supervisory systems and or to to controllers.
It'll do the actual simulation of a controller so it thinks it's talking to real,
but it's talking to emulate 3D.
So we can do much more high fidelity, emulation of a system.
Then we have the default framework that I just mentioned that's under development to
help us introduce various areas in all different disciplines.
And there's a lot of aspects that we have to, to allow you to, to create those, to monitor
them, to log them and to to control when they take place.
And then we have a scheduler and a scenario manager that says at this time, run, run this
scenario, do it with this version of the file before you start up. So set these values.
So restore snapshot to a particular state, then run for x seconds, minutes, hours, then
introduce these faults and and make sure that the code detects that correctly and reports
it out. Right.
And and that all needs to be an unattended automated testing, which is something that
that has not been in place for PLC code certainly in the Rockwell environment in the
past.
And with this tool, we believe we're adding a lot of capability to the developers to stay
much closer to the quality of their code.
It doesn't always have to be the entire project at once, but yeah, we will make
progress there. So stay tuned.
This is for us a major development area.
So that gets us to training commission start up and again, we're reminding you that, you
know, in the beginning we looked at these as kind of critical path items that were done in
sequence and everything we're talking about is taking this system, taking this process
and able to move things up onto under non-critical parallel processes. So here's an
example.
This looks back a little bit to a video we showed earlier. We're going to loop it a
couple of times.
You remember this, this lift lifting, this car body.
And if we watch this carefully, something really interesting that was learned that if
this was learned on site when it was being commissioned would be very challenging.
Why don't we run that one more time to. And if you look at the car, the frame here,
you'll see that there is a shield on the engine just there, that kind of salmon
colored. And look what happens to it when it hits the agv.
It actually goes down in this case through the agv in the real in the real world, that
would have been a crushing interference.
And that's something that emulate 3D was able to show the user here they were able to
actually see in a virtual environment before this system was ever finished, before it was
completed.
What happened when that car body was set down.
So that was their cad, that was their agv. And when putting those together in the active
environment, they were able to see exactly what happened.
So these are the kind of things that able give you the ability to do that virtual
commissioning.
And when we say virtual, we mean that very, very deliberately that allow you to reduce
that kind of, you know, expensive, ad hoc design changes.
One thing that Antwon always says, and I am and as someone that has experience that he
has over the many years is true, is if you're finding these things out on site, it's way
too late because you will not make the right decisions to fix them.
You'll make the fastest, cheapest decision to try to get things working.
And that's not the way to do it, right? We want to make the right decision and
usually to make the right decision and the right fix.
We need to do that early so that early detection of the relationship between the
mechanics and the controls is just highly critical.
And it's something that emulate 3D gives us. Here's another example a retrofit project
with this fairly complex billet handling operation where we have these large aluminum
billets that are being moved and handled all all robotically.
And if we look, we this user was actually able to do something very interesting.
They were evaluating the software, if you will, and they were able to take what you see
is actually a evaluation version of emulate 3D.
And they were able to build a model of this system and implement the way the changes were
going to work, that they were going to implement in the model and connect it to the
HMI.
So this HMI is actually running a virtual model of that billet handling machine and
they were able to analyze all the changes they were making with, in fact, the changes
not only to the controls but to the HMI as well.
And do that all within what was an evaluation period of the software.
I think it ended up being about 5 or 6 weeks. So very quickly. And that wasn't full time,
right? That was just the time they had the software
very quickly able to start to look at these systems, evaluate them and make decisions.
And those are the kinds of things we see over and over again.
And sometimes what seem like small concerns become big concerns when you can look at them
virtually.
And and get them fixed and realize the costs that you've saved.
let's talk a little bit about the kind of outcomes that people achieve from virtual
commissioning these outcomes that we've listed here and on the next slide are from a
user of emulate 3D who works. They're a large OEM.
They work with Big three automotive manufacturers and they routinely talk to us
about the success they have with virtual commissioning.
They become in many ways a powerful user and a great partner, you know, so some of the
things I won't read through all these because I know that as you're reading, as you're
viewing this, you're reading through them.
But they were able to test the mechanical element placement. They're able to test
logical responses to the mechanical inputs.
They're able to look at the electrical power and wiring layout when it comes to control
design and tests, they're able to look at logical sequences.
They're able to look at the HMI and operator actions and the fault response throughout
that system and then the kind of onsite experience they're able to look at the
mechanical and electrical logic right before they're on site, they're able to look at
operators and maintenance teams that they're able to take them and get them familiarized
with the system.
They're able to start preparing for troubleshooting based on how they think that
real system is going to act based on how the model acts right.
The model, again, all models are wrong, but some are useful, and many of these models are
very good at predicting the kind of things that could or should happen in a system.
And then reducing the time between design, completion and production milestones. And
this is what it looks like.
If we look at all their projects that they've analyzed with with emulate 3D.
So of the recent projects that they've done, there's been seven projects, four that were
done under under budget and three at budget and zero that required extended
commissioning.
And those are the ones that were where they use digital engineering, right?
Then there were three other projects, I believe. Is that right?
Antwon Was it three others or is it two? I think this these were two they've done many
projects without sorry, with no digital engineering used.
And you see that project went over budget. It was extended by three weeks and the other
one over budget and by four weeks.
So this is really common because what has happened, I guess historically over time,
people have, I guess you could say, gotten used to the fact that projects tend to run
over budget and over time.
And what we're really trying to do is realign the way people think and allow them to
estimate projects better and complete them within the estimation by taking a whole bunch
of those activities that are usually done at the end, that are done on site, that are done
in a high risk environment, in a high risk timeframe, and begin to move them up again
under that parallel path.
So that we're removing that risk. And this is real.
I mean, this is real life feedback from the users of the software and users of this
digital engineering focus within the world. Yeah.
And then the last bit we have and by the way, Tyler, that reminds me of my, my first,
virtual commissioning customer who came to us and said I had a project.
We had the equipment coming from three separate sites.
One of them was providing the front end of the machine, one was the middle, one was the
end.
And they, they came on site. They all started to build up.
And about two days before the commissioning needed to start, the foreman of the middle
machine says to the front machine, Hey, can you place that last little bit of conveyor?
And the answer from from the guy at the machine up front said, That's not in my
scope.
That's in your scope. And that set them back three weeks, right?
While they physically had to build this missing piece of equipment.
And and that alone was enough for them to say never another project without a digital twin
to validate that, that our systems are correct. Yeah.
So anyway, getting back to operation and maintenance, once we have that twin.
Yeah, we have a test bed we can do ongoing experimentation and we can start properly
doing doing operator training.
And here we're looking at some extended reality view of a line in this case, it's
it's pure virtual reality.
But we also see people doing it in in mixed reality.
and you're seeing here two people in the machine together looking at the line and
trying to work at different elements and see do I have everything I need to control it.
So one of the elements that will zoom on, zoom into in a moment is the HMI.
And they will actually go and and operate the HMI and see if all the functions that the
operator has available on that HMI are enough to properly run the line and to diagnose
different situations.
And because they are in that in that environment, what they see is absolutely what
they will see in, in real life.
And so, yeah, the VR experience is, is an interesting aspect.
You can see if you can see your tower lights from where your operators positioned, you can
see it when he is abusing the line and affecting the product quality.
But in general, lots of useful applications for this, this interacting between the model
and the and the system.
So that brings us to, to really the summary of why we're doing this, this digital
engineering.
We want to reduce our product timelines, know we want to expand our design possibilities by
making it much easier to iterate designs, to experiment with scenarios and to design
rapidly within a within a model reducing.
I've had OEMs who have reduced their prototyping, the physical prototyping from
eight prototypes to two because they could do so much more in their in their digital twin
environment right?
And then reducing risk by commissioning before going on site.
You can't overstate the value of that. The code quality, everything is so much
better when you've had a chance to develop in a in a secure environment.
So our dynamic, dynamic, digital twin creates a functional twin of a system focused on the
functions that mattered to you as a controls engineer, right?
You don't have to have every last bit of that model be 100% correct.
But you're looking for is what are the things that affect my model's operation?
And especially my control system behavior.
You know, where is that that low hanging fruit of of most benefit to my controls,
testing and least effort for a building.
The building the application and then allowing you to improve it.
So back to what function do you need rather than which function could you implement if
you had infinite time and budget?
And we if we need more detailed models, we can of course link into third party
simulations, involve the the studio 5000 simulation interface where we can do model
based control, things like that.
And then of course our linkage into Echo where we can run without hardware on hand yet
get that full PLC behavior with the same firmware and the same application that's
running in the real world.
And all in all, we we have seen our flow.
You know, we, we've done a we're doing a good job of reducing the overall cycle of a
project so we can start our automation design much earlier.
we can start our controls testing, we can do our commissioning, our training and when the
system is up and running, we can still do that, that operate and maintain.
So, all and all, yeah, we, we believe it's a, it's the way to go forward and especially in
typical projects where Rockwell applications are built, where we see dynamic always
changing control system requirements, virtual commissioning and just a fantastic amount of
value to to our customers.
And with that, I believe we're ready for questions and thanks. Yeah, Thanks, Andrew.