Calculations are used to compute something using a given expression (formula) and specified inputs. This seems like an incredibly obvious statement, but there are a couple of important observations to note.

Firstly, let’s look at an example calculation for Efficiency. If we have an Energy In and an Energy Out, we can use a calculation to determine the Efficiency as follows:

Efficiency = ( Energy Out / Energy In ) * 100

Observations:

For this calculation to be globally true, What each of the inputs (variables) represents must be explicitly defined. Equally so, What the calculation is calculating (its output) must also be explicitly defined. We can use the exact same tags as we used for attributes to do this. Taking our simple calculation from above, we can match the variables used to what their tags would be:

Once we have explicitly defined What the inputs to and output from the calculation represent (i.e. their tags), we can use that calculation again and again, wherever we find attributes which match each of the variables required (by comparing tags). Note that an attribute may have many more tags than those required to be considered a variable, but that doesn’t matter.

It is through this mechanism of defining the Whats (again) of the calculation, that we can capture our engineering knowledge. This engineering knowledge is not limited to any particular asset or site (though we may force it to be), it can be used anywhere else that the tags fit.

The calculation definition, therefore, exists entirely independently of any other entity.

It’s a good question. If we’re saying that to do a simple calculation the user has to instead define collections of tags for each of their intended variables and that they must use these in place of their own named variables, it simply won’t work.

An important note to remember is that a calculation falls under the Where consideration, as in where the data comes from. As we are enforcing a particular workflow within our asset and attribute creation, we know that the What will always be known before the Where.

By utilising the same workflow (or wizard?), we can allow a user to create a calculation for their own instance of an asset and its attributes, and unbeknownst to the user, extract their engineering knowledge for later use. That sounds a bit mad, so let's look at an example.

Say a user has created an asset and populated it with two attributes so far:

They are now in the process of adding an additional attribute, which they want to represent the efficiency of that asset. They fill out the Name and Quantity (efficiency). The wizard recognises that efficiency doesn’t have a Subject or Section and so proceeds to prompt the user for a Source. The user decides to use a Calculation as the source for this attribute.

Note that at this point, we already know What the user is trying to calculate and we also know What other attributes are available on the asset.

The user is presented with a calculation builder wizard. The wizard limits the variables that the user can use in the formula, to attributes which already exist (and have all their tags). The user then defines the following formula:

Efficiency = ( Steam Out / Gas In ) * 100

Note that we have shown the attribute’s name in place of a user-defined variable name, but the user would be free to define their own variable name and just say that the input comes from a particular attribute.

A new calculation can then be created with the following tag requirements for its variables:

At this point, the engineering knowledge has been extracted (for later reuse, scoped accordingly) and the user can simply select this new calculation for use with their particular attribute.

Once complete, their node would have the following attributes:

So far we have looked at a very simple calculation. The tools within CoolPlanetOS allow us however to create a far more complex calculation. functions available to sue within a calculation should be familiar to users from other software tools they regularly use to manually dissect data.