# Understanding the Device Simulator Functions

**URL:** <https://forum.inductiveautomation.com/t/understanding-the-device-simulator-functions/103195>\
**Category:** Ignition\
**Tags:** opcua, ignition81\
**Created:** [March 4, 2025, 9:53am UTC](https://forum.inductiveautomation.com/t/understanding-the-device-simulator-functions/103195 "2025-03-04T09:53:58Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![Robert\_Collinson](https://avatars.discourse-cdn.com/v4/letter/r/7993a0/32.png) [@Robert\_Collinson](https://forum.inductiveautomation.com/u/Robert_Collinson)\
**Post date:** [March 4, 2025, 9:53am UTC](https://forum.inductiveautomation.com/t/understanding-the-device-simulator-functions/103195/1 "2025-03-04T09:53:58Z")

</div>

Hi all,

I'm attempting to understand the OPC UA device simulator a little more as I want to simulate a basic device (a limit switch), only, having read through the description of each Function, and, the available Parameters, I'm struggling to understand what each of the Parameters mean for the 'realistic' function.

In my defense, I'm pretty new to the world of OPC/Logic controllers, and, reading through the explanations for each of the associated parameters seems to suggest that they were written with a degree of assumed knowledge.

Being a resourceful type however, I attempted to load up the Generic Device Simulator, which, according to [this post here](https://www.docs.inductiveautomation.com/docs/7.9/opc-ua-and-device-connections/simulators#realistic) (ok, ok, yeah, it's a 7.9 article...I just can't find the 8.1 equivalent) should contain some examples of it's implementation.

The problem I have with this though is that it suggests the simulator should be representing the Function with the following timings and parameters:

 ![Ignition Generic Device simulator - Realistic](https://us1.discourse-cdn.com/inductiveautomation/original/3X/a/2/a2a02bbb18045769d2e813583e3018435a40086d.png)

If implemented according to this schema, I assume that this would have given me a fantastic opportunity to better understand this for myself.

However, when I loaded up the simulator, and, proceeded to edit the program, I was presented with the following parameter settings:

 ![ignition Generic Device Simulator - Realistic Implementation](https://us1.discourse-cdn.com/inductiveautomation/original/3X/9/e/9e33e3db0b3206fdf40af60705718549e42d1866.png)

I'm not sure I can connect what the article is suggesting with these settings.

Am I correct in thinking that this isn't how it should be configured based upon the settings illustrated in the article, or, am I misunderstanding something here?

Can someone maybe assist me with a more verbose explanation behind each of the parameters used with this function, and, maybe, update the 8.1.x Ignition User Manual website with this information too?

I mean, I suppose i could search the Interwebz for an explanation. However, I couldn't ever be sure that what the internet suggests could be the meaning would tie up exactly with how Inductive Automation have realised/implemented this within Ignition...it being somewhat of its own ecosystem after all.

Many thanks in advance for anything anyone can provide!

---

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [March 4, 2025, 3:49pm UTC](https://forum.inductiveautomation.com/t/understanding-the-device-simulator-functions/103195/2 "2025-03-04T15:49:05Z")

</div>

The old simulators were deprecated (for a variety of reasons) and their functional purpose absorbed into the new "programmable device simulator"; if you choose a specific program for the new sim it acts in a slightly special way to simulate the legacy devices; I would recommend _not_ doing that if you're just trying to explore things for learning purposes.

The new simulator is documented here:

> **[Programmable Device Simulator | Ignition User Manual](https://www.docs.inductiveautomation.com/docs/8.1/ignition-modules/opc-ua/opc-ua-drivers/programmable-device-simulator)**
>
> The Programmable Device Simulator allows you to add simulator devices that act as if they are connected to a real device. It allows users to read and write Tags without any network or PLC connection.

---

<div class="post-metadata">

**Author:** ![Robert\_Collinson](https://avatars.discourse-cdn.com/v4/letter/r/7993a0/32.png) [@Robert\_Collinson](https://forum.inductiveautomation.com/u/Robert_Collinson)\
**Post date:** [March 5, 2025, 8:57am UTC](https://forum.inductiveautomation.com/t/understanding-the-device-simulator-functions/103195/3 "2025-03-05T08:57:09Z")

</div>

Hi PGriffith,

Thanks, however, I'm aware of this link.

My problem is that having read it, as explained, I'm still at a loss as to how the Realistic Function works.

As I explained, the description of its Properties is not at all sufficient for me to get a good read on what it's actually doing.

That is when I broke out the included Device sims to see if I could potentially better understanding how what was documented for the Generic sim was being realised within the simulator available to me in 8.1.

Although I'm still uncertain as to why I shouldn't use them, my thought was that at least it would allow me to work out what I was missing from the descriptions assigned to each of the properties for the realistic function.

In fact, the lack of understanding with regards to the description is what is preventing me from going deeper into the _programmable_ aspect of the simulator myself.

Is there a chance someone has the knowledge to expand on a simple _read-back_ of the word used to as a the place holder for the function's property:

 ![ignition Generic Device Simulator - Realistic property explanations](https://us1.discourse-cdn.com/inductiveautomation/original/3X/5/2/523a2bb9e7dde668db5e640e2a23f950b4db71aa.png)

I'm sure that these words mean something to some, however, I do not have the baseline knowledge and therefore do not understand. Also, I have no understanding of the three letter acronym PID other than, say, maybe, process ID. However, how such a thing would relate back to the function placeholder name, I haven't a clue.

Many thanks once again.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [March 5, 2025, 12:57pm UTC](https://forum.inductiveautomation.com/t/understanding-the-device-simulator-functions/103195/4 "2025-03-05T12:57:48Z")

</div>

"PID" is "Proportional-Integral-Derivative", an _ **extremely common** _ feedback control strategy in real world process applications. Google it.

---

<div class="post-metadata">

**Author:** ![lrose](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lrose/32/62724_2.png) [@lrose](https://forum.inductiveautomation.com/u/lrose)\
**Post date:** [March 5, 2025, 2:57pm UTC](https://forum.inductiveautomation.com/t/understanding-the-device-simulator-functions/103195/5 "2025-03-05T14:57:41Z")

</div>

> [@Robert\_Collinson](#):
>
> Also, I have no understanding of the three letter acronym PID other than,

When you first start looking into process control you'll run into two different types of control loops, Open Loops and Closed Loops. The difference is that Closed loops ~~take "part" of the~~ measure the output and feed it back into the loop, this is known as "feedback".

In PID this feedback term is used to calculate the error. The two other terms you need to know to get a general understanding of PID are the "Set Point" (target) and the "Process Value or Variable" (actual). The error is the difference in these two. So you end up with a control loop that looks something like this:

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/e/f/ef3b477c0d9b93a1ac46f4e571fa163790274b17.png)

For instance you might have a Pressure control valve (the controller) controlling the pressure in a tank (the system), and there is a Pressure transmitter (Measuring element) on the tank which is reading the pressure (Process Value).

So, the sum of the error and the set point is fed into the controller which drives the system, the process value is then measured and fed back into the system. This happens continuously until a steady state is reached.

There is some complicated math that goes on, but generally this interaction is mashed together into what is called the systems "Transfer Function", and what we are really interested in is at the beginning of this loop in the "comparator".

Essentially what the PID is attempting to answer is this question:  
"Given a set point what output should I send to the controller to move the process value to the set point?". The controller here can be many different things from a Pressure control valve to a VFD.

The most basic equation for a PID looks something like this:

Output = Kp \* _e_(t) + Ki \* Σ_e_(t) + Kd \* Δ_e_(t) / Δt

So the Proportional Gain (Kp) is how much the instantaneous error is accounted for in the output. In other words, the output is directly **proportional** to the error. The goal being that the error is driven to zero.

The Integral Gain (Ki) is how much the sum of the error over time (the **integral** ) is accounted for in the output. So over time the output will increase (or decrease) according to the integral gain in order to drive the sum of the error to zero.

The Derivative Gain (Kd is how much the rate of change of the error (the **derivative** ) is accounted for in the output. So over time the output will increase (or decrease) according to the derivative gain in order to drive the rate of change of the error to zero.

There are reasons that these gains are used or not in different scenarios. For instance the derivative term tends to make the system susceptible to noise and so is often avoided. When a particular gain is not used then it is standard to drop that letter from the acronym so you might see things like: PI controller, Proportional Controller, PD Controller.

It's a very large topic with a whole bunch of applications, but if you're going to venturing into the world of control systems it's one that you will want to get versed in.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [March 5, 2025, 3:52pm UTC](https://forum.inductiveautomation.com/t/understanding-the-device-simulator-functions/103195/6 "2025-03-05T15:52:41Z")

</div>

> [@lrose](#):
>
> The difference is that Closed loops take "part" of the output and feed it back into the loop, this is known as "feedback".

`<pedant mode="true">`

No, closed loops **measure** the process to use in the math to produce an error signal, which allows the controller to adjust for varying conditions. The _measurement_ is the feedback. The setpoint must use the same units and scaling for the math to work.

Open loops simply compute an output, via some model of the process, from the setpoint (no error signal) and blindly assume it works. No feedback at all.

Closed loops may also use a model in the controller for better performance.

`</pedant>`

---

<div class="post-metadata">

**Author:** ![lrose](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lrose/32/62724_2.png) [@lrose](https://forum.inductiveautomation.com/u/lrose)\
**Post date:** [March 5, 2025, 4:20pm UTC](https://forum.inductiveautomation.com/t/understanding-the-device-simulator-functions/103195/7 "2025-03-05T16:20:18Z")

</div>

Yeah, I was trying to keep it “simple” and got in my own way.

Thanks

---

<div class="post-metadata">

**Author:** ![Robert\_Collinson](https://avatars.discourse-cdn.com/v4/letter/r/7993a0/32.png) [@Robert\_Collinson](https://forum.inductiveautomation.com/u/Robert_Collinson)\
**Post date:** [March 6, 2025, 3:10pm UTC](https://forum.inductiveautomation.com/t/understanding-the-device-simulator-functions/103195/8 "2025-03-06T15:10:04Z")

</div>

ahaa, being a newbie to electro-mechanical (or other non electro-mechanical) process design/analysis this was not at all immediately obvious.

Cheers for the heads up, I will now endeavour to read up on the subject.

---

<div class="post-metadata">

**Author:** ![Robert\_Collinson](https://avatars.discourse-cdn.com/v4/letter/r/7993a0/32.png) [@Robert\_Collinson](https://forum.inductiveautomation.com/u/Robert_Collinson)\
**Post date:** [March 6, 2025, 5:11pm UTC](https://forum.inductiveautomation.com/t/understanding-the-device-simulator-functions/103195/9 "2025-03-06T17:11:27Z")

</div>

Although I sorta kinda followed, this, I had to run it through a GPT to translate somewhat.

A good example it came up with was a cruise control system for a car.

It would monitor the final speed to understand how short it is of the target speed. The further away the higher the correction factor would be.

It would at the same time keep a record of the number of speed readings taken along with how far away (plus or minus) the reading currently is, and therefore the distance from the set point (i.e. zero error) it is since the point it was engaged to understand the overall situation and the correction factor which should be applied as a result to smooth out any potential for a jumpy response.

Again at the same time, the system works out the number and size of changes being applied (the rate of change) and works out whether it may be applying too much of a or too many change(s), or, on the flip side, whether it's applying too few.

All these factors combine to even out the rate and amount of change to hopefully result in smooth/optimal transitions as the system 'fights' to maintain an equilibrium (i.e. the target speed).

So, that all said, how is the simulation working if the factors are set and we're not supplying a real life value stream (feedback loop of the speed of an actual car, pressure reading on an actual valve etc.etc.) into the function?

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [March 6, 2025, 5:25pm UTC](https://forum.inductiveautomation.com/t/understanding-the-device-simulator-functions/103195/10 "2025-03-06T17:25:57Z")

</div>

> [@Robert\_Collinson](#):
>
> Again at the same time, the system works out the number and size of changes being applied (the rate of change) and works out whether it may be applying too much of a or too many change(s), or, on the flip side, whether it's applying too few.

That's a too optimistic idea of what a controller does.

A PID controller applies three simple factors to produce a control output:

- Error × Proportional factor. _ **Set** _ throttle linearly based on speed error. No memory of past action.

- (Time summation of Error) × Integral factor. _ **Ramp** _ throttle based on speed error. This is the primary memory of past action.

- (Changes in Error) × Derivative factor. Bump the throttle up or down to handle relatively sudden speed changes. This is a tweak to avoid overshooting, using memory of past _measurement_, not memory of _actions_.

FWIW, my engineering education devoted an entire semester course to "Feedback Control Systems". Don't be discouraged if it doesn't "click" immediately. It is worth noting that PID control is an attempt to mimic what humans naturally do with eye-hand coordination when manually controlling some physical process. Or in the case of a car, eye-foot control of the throttle pedal.

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [March 6, 2025, 5:42pm UTC](https://forum.inductiveautomation.com/t/understanding-the-device-simulator-functions/103195/11 "2025-03-06T17:42:16Z")

</div>

Don't make the mistake of thinking the device simulator is Serious Software.

It was a cheeky under-spec'd hack that somebody whipped up because training needed more ways to have OPC values that change in various ways during their classes.

---

<div class="post-metadata">

**Author:** ![Robert\_Collinson](https://avatars.discourse-cdn.com/v4/letter/r/7993a0/32.png) [@Robert\_Collinson](https://forum.inductiveautomation.com/u/Robert_Collinson)\
**Post date:** [March 7, 2025, 9:29am UTC](https://forum.inductiveautomation.com/t/understanding-the-device-simulator-functions/103195/12 "2025-03-07T09:29:35Z")

</div>

oh yeah, i get it...I just wanted to better understand what it is this particular function is actually doing...something that, although thanks to the responses here I'm starting to get more of a handle on (although, the more I read the more i realise I'm still very much in the tundra towards to the base of the foothills), it still isn't exactly clear to me what it is doing.

So, we appear to have values for the desired outcome and the control rate to temper the over/undershoots, but, I'm still somewhat at a loss as to how it generates the numbers representing the 'result' or output.

I see that typically for example, the set point is 100 by default, yet, when we fire up a test device and watch what it's outputting, I see values of 140+ appearing.

Given that, its difficult to understand what exactly the logic is driving the output of the function.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [March 7, 2025, 12:40pm UTC](https://forum.inductiveautomation.com/t/understanding-the-device-simulator-functions/103195/13 "2025-03-07T12:40:48Z")

</div>

> [@Robert\_Collinson](#):
>
> difficult to understand what exactly the logic

It is not just running the math for the PID algorithm, but _ **pretending** _ to be a real process controlled by such and algorithm, with random noise and disruptions. Because it is a **simulator**.

---

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [March 7, 2025, 3:28pm UTC](https://forum.inductiveautomation.com/t/understanding-the-device-simulator-functions/103195/14 "2025-03-07T15:28:36Z")

</div>

Yep, quite literally just random noise is added while updating.

```python
                double noise = random.nextGaussian() * 0.8; // gaussian distribution with standard deviation of 0.8

                currentValue = currentValue + update + noise;

                if (random.nextDouble() < changeTargetProbability) {
                    // gaussian distribution with standard deviation of 50
                    setValue(new DataValue(new Variant(currentValue + (random.nextGaussian() * 50))));
                } else {
                    setValue(new DataValue(new Variant(currentValue)));
                }

```