The Standard Caution About Abstractions applies to this page.

 

Two or more variables are “orthogonal” with respect to each other when the value¹ of any strict subset² has neither causal nor statistical relationship with the value of any distinct³ strict subset.

This concept pervades Mathematics and Engineering.  The elements of such a set are “independent” or “uncorrelated”.  It is conceptually similar to “principle axes”, “principle components”, and “bases”.  The set can be construed as “canonical”by virtue of each variable’s isolated influence on the value.

The preference for “orthogonal” over alternative terms elicits some useful concepts from topology.  Each such variable can be construed as one dimension in a space⁴ formed by the entire set.  With the application of tolerances to the values of individual elements, a region can be formed in that space.  Certain types of values⁵ admit to the specification of sub-spaces⁶ that aid in the identification of interaction and potential contradiction with those that are immediately in the parent set.

The region described above can be rigorously used to discriminate between other sets of data⁷ asserted as enveloped by that region.  The potential for auditable rigor mitigates opportunities for cognitive errors in discrimination processes, including biases that are enhanced by confuscation.

Because it requires assessment of potential overlaps between topics, orthogonality can be difficult to establish.  When feasible, it enables reference to exactly one thing at a time without having to consider how it influences, or is influenced by, other topics.  When used in the context of requirements, it is the implicit foundation for the notion that each requirement “stands alone”.  Even when not completely feasible, investigation of orthogonality enhances the understanding of such interactions and their implications.

Examples

(1) The X-axis and Y-axis typically used in basic algebra are orthogonal in the most commonly used sense of the word.  Any point on the X-axis can be arbitrarily associated with any point on the Y-axis.  The paired X and Y elements of a discrete representation of the line Y = X + 1 are not orthogonal.  They have a relationship associating the values of one (Y) with the values of the other (X).

(2) The functions of that dadgum door might be construed as “open” and “close”.  While many practices would consider that to be a valid set of functions, they’re not orthogonal: they cannot be simultaneously  invoked.  It might be better to construe a single function (e.g. “control aperture”) with aperture and aperture rate as parameters.  In the requirements (which are abstract), the two parameters would be orthogonal.  In a concrete design, they are not orthogonal, being correlated by finite acceleration and impulse.

(3) Suppose that we have a room with bi-directional doors on opposing walls.   Their functions are orthogonal: either can move freely no matter where the other one is.  Tie their knobs together with a stout rope that exactly spans the room, and their functions are not orthogonal: they can’t both swing outwards at the same time.  In the limit of this notion, we can tie them together with a stiff rod.  Their positions are fully interlocked: they’re not really two things at all.

(4) Table 9 of the Orbital Parameters example identifies relationships between columns in the tabulated source data.  In the Relational Paradigm, the existence of transitive relationships means that the columns are not orthogonal.  Removal of such relationships resulted in qualitative changes in how those data were stored and accessed, splitting a single complicated table into several simpler ones.  Each of the resulting tables has a set of columns that is orthogonal, storing the data that are directly pertinent to exactly one “topic”⁸.

(5) Statistical variables are orthogonal when their covariance is zero⁹.  The “Root Sum Square” (RSS) and “Root Mean Square” (RMS) techniques of tolerance analysis rely on the “tolerance stack” elements having zero covariance and, therefore, being orthogonal.  When the dimensions have some common factor, they are not orthogonal: their covariances are not zero, and the RSS and RMS techniques are not applicable.

(6) In structural/mechanical design, a dimensioning scheme that is capable of internal contradiction is considered unacceptable: exactly one “controlling” sequence is permitted for any given physical feature, with all others being explicitly labeled “reference”.  A proper dimensioning scheme constitutes an orthogonal set¹⁰.  Failure to identify and label reference dimensions results in a dimensioning scheme that is not orthogonal: the shop might (or might not!) build what you thought you requested.

Observations on Feasibility

Although theoretically attractive, a general process requirement for strict orthogonality of either topics or their associated parameters is not always practical.  Feasibility and benefits vary for different Developmental phases, being of greatest practicality during processes that produce abstract data.

Such an assessment must be conducted for each pair of variables, for each triplet, each quadruplet…each “tuple” up to the number of variables (n).  If inductive reasoning hasn’t failed me¹¹, the number of such assessments is something like

I have always suspected that the astonishingly large number produced by this equation is nature’s way of telling us not to write too many requirements¹².

When defining development requirements, the magnitude of the task can be mitigated by careful specification of topics and assertion of their independence.  An assertion is supportable because the purpose of requirements is to communicate intent to the design and verification communities.  Intended absence of interaction can, and probably should, be explicitly specified¹³.  Permissible interaction can be inferred by lack of such specification, or addressed as a matter of standard, published practice¹⁴.

It is much more difficult to produce orthogonal topics and parameters when characterizing concrete technologies or an existing hardware design, because Physics is harder to ignore when dealing with manufactured parts¹⁵.  Many aspects of formally-defined “System Identification” techniques exist to develop orthogonal parameterizations, for exactly the reasons addressed in this website.  The resulting factors (unfortunately) are often unsuitable for writing executable requirements.

Footnotes

1.   Which can be an array.[↩]
2.   Any combination of one or more members of the set, up to but not including the entire set itself.[↩]
3.   mutually exclusive[↩]
4.   Not necessarily a metric space.  There’s work to be done before that can be claimed.[↩]
5.   Pointers to configuration-controlled documentation. [↩]
6.   Using topical analysis and parameterization recursively. [↩]
7.   Perhaps having been transformed from some other basis.[↩]
8.   Each row being a separate populated instance of that data structure.[↩]
9.   This is the same as saying their correlation is zero.[↩]
10.   Not to be confused with a “frame of reference”.[↩]
11.   As it sometimes is wont to do![↩]
12.   A foreign concept to many System Engineers.[↩]
13.   Although violation of the Laws of Physics is generally frowned upon. [↩]
14.   The issue can also be ignored, to sow the usual chaos and confusion.[↩]
15.   Certain kinds of software, on the other hand, can blissfully ignore little things like Physics.[↩]