Translating mathematical equations into code is part of, but also removed from, the development of automation projects involving computer solutions. We must consider the efficacy of the mathematical equations relative to the needs of the project being developed. We must also consider the solution method for solving the equations with the data and timing involved.

Data issues that reach the solution algorithm must be detected, controlled, and when possible, corrected. Precision management must occur at various stages of the process. Errors created along the way by the solution process and implementation must be detected and managed.

This is a subject for books, but hopefully the thought process can be moved along with a few hundred words.

First, keep in mind that not everything we do not make specifically deterministic is, by default, stochastic. Computers and the procedures by which they solve problems can introduce obscure biases that, with analysis, are clearly deterministic—just not intentional. The simple ones that illustrate the problem go to precision. In many instances, we would like to think that intermediate values are exactly right or at least rounded using criteria we know from mathematics.

At various levels, truncation—instead of rounding—forces calculated numbers to fit into the variable size provided for them. Sometimes this doesn’t matter, but sometimes it introduces biases. It can be useful to use mathematical procedure and practice to actively manage the stored value of all calculated values so that the solution engine preserves the accuracy expected for them. This is commonly taught in programming classes, and frequently neglected because understanding and managing precision is boring and tedious.

Sometimes the observations lack consistency (e.g., because of sampling or synchronization issues) or reliable precision at the instant of measurement (e.g., due to transient instabilities). There are often ways to clean that up (e.g., by boundary limit checking, data analysis, and regression techniques). There are often ways to make something more than disclosed by the data stream, but many of them involve programmer conjecture about what may be happening. Be careful of this—a good outcome is too important to reject a priori, but an incorrect result can be more damaging than the value of the potential improvement it facilitated.

Sometimes the solution procedure itself, even with appropriate precision management, can introduce problems. Suppose we want to integrate a streaming function from now to infinity. Even very small errors or ambiguities, insignificant in a single calculation, grow to astronomical values when continuously accumulated over long periods of time. This can get mixed up with rounding and truncation and produce a disparity due to continuously biased measurement or integration methodology. This can manifest over time in huge errors, for example, in the “I” term of a PID controller. There are data control and precision management procedures, as well as mathematical ways of approaching the problem for the needed solution that resolve these issues, but the path to discovering them can be embarrassing.

Sometimes mathematics gets applied to a requirement without fully understanding the problem, the mathematics, or what the mathematics is actually designed to do. It may be possible, for example, to sometimes detect a situation and other times completely miss it using the exact same math.

If you would like more information on how to purchase the author's book, Detecting Leaks in Pipelines, click this link. You may also download a free 37-page excerpt from the book.

If the data for a particular case contain the situation the mathematical procedure is designed and constructed to detect, the designer will look brilliant every time. On the other hand, if the data set contains the problem of interest but not the features for which the mathematical procedure is designed to detect, then the condition will not be detected. Simply put, the mathematics detects what the equations and the underlying physical laws are designed to detect. It may typically be a component of the subject event, but not always a component. Put another way, the condition the system is intended to detect must be a member of the set of things the chosen mathematics can find. Dealing with this problem is why people who work in this field usually have six to twelve more units of advanced math than people who don’t.

An outlier or two can spoof an algorithm into thinking a truth has been discovered when the reality is some sort of measurement problem.

Statistics uses specific methodology to discern certain population conditions from small samples, largely by sample sizes that are managed in timing and precision, to ensure that what is being evaluated is in fact representative of the whole. A sample size selected for a common data problem may be hopelessly small for a slightly different one.

Because of steps in the procedure, solutions appropriate for a specific problem may be completely inappropriate for the same event occurring in a different way or a different place, or with an inappropriate selection of relevant time. Remember, the math has to properly describe the process for which you are looking. That for which you are looking must be “true all the time”—for all manifestations of the desired event as it can appear in the process.

In essence, an incomplete understanding of the process, the solution mathematics, and the design methodology can get in the way of coming to the proper conclusion. This kind of thing can be the difference between obfuscation and solution for the equipment user. Lots of things are simple and, with some care, obvious. The ones that aren’t, though, can be very irritating.

Interested in reading more articles like this? Subscribe to ISA Interchange and receive weekly emails with links to our latest interviews, news, thought leadership, tips, and more from the automation industry.