This is the second of three pages on the topic of parameterization, dealing mostly with the consideration of parameter sets. The previous page dealt with topical parameters as individual items. The third page deals with aspects of evaluating them.
My Standard Caution About Abstractions applies to this page.
Introduction
Individual topical parameters are useful because they clarify the distinction between (1) the qualitative idea of a particular characteristic, and (2) how we intend to quantify it. That separation makes it possible for us to sidle up to the problem piece-wise and to explain the evolution of a project’s System Engineering approach in easy-to-digest portions. Sidling and good digestion are both useful for all the usual reasons.
Most dingae, however, are described by more than just a single topic, and many topics are best characterized by sets of related parameters. We are, in effect, explicitly identifying two orthogonal layers of set-building abstraction1: at the topic-level, and at the dingus-level. Together, the abstraction layers supply a bit more rigor by combining three concepts from the physical sciences, higher mathematics, and Computer Science to grapple2 with “commensuration”, “dimensionality”, and “matrix notation”.
Three Concepts
1. Commensuration
In the context of the Physical Sciences, two mathematical expressions3 are “commensurate” when they quantify the same abstract property. For example, two lengths can each quantify a span in one dimension of the familiar 3D space; the underlying dimension(s) are not necessarily parallel. Lengths are considered to be “commensurate”, without regard to whether they happen to have the same magnitude or direction.
When used this way, the concept of “commensurate” is analogous to the concept of “equal”, but is more abstract. The precise application of the concept depends on how the parameters need to be defined for the particular problem at hand.
The parameters defined in this practice conceptually correspond to the physical quantities formally defined in ISO-80000 (International System of Units, or SI). In the US, the SI is called for by the National Institute of Standards and Technology (see Special Publication 811). In particular, consider the “base quantities” defined by the SI, shown in Table 1.
| Length |
| Mass |
| Time |
| Electric Current |
| Thermodynamic Temperature |
| Amount of Substance |
| Luminous Intensity |
By definition, non-base properties that can be “reduced” to share the same arrangement of the base properties are considered to be commensurate.
Aside
The statement “…are considered to be commensurate…” is mostly true in the SI, but not completely true. It was an objective of the effort, but it didn’t quite come about. By not uniformly distinguishing between the even-more-abstract concepts of position and displacement, the resulting system introduces some peculiarities. This leads to a unique handling of temperature in the standard, and to dimensional ambiguity between (for example) torque4 and engineering work5. In both examples, the ISO uses a single base property for both position and displacement (e.g., absolute temperature AND change in temperature) and, therefore, the same units. Such ambiguities can only be resolved in the context of usage, rather than through the units or dimensions alone.
Bearing in mind this somewhat abstract issue, however, the statement is adequate to most Engineering purposes, and the concept is useful as a template for the present discussion.
Additional properties, defined as combinations of base properties, are referred to by the ISO as “derived”. The concept is useful in the SE context because it provides an independent basis for us to be reasonably confident that when we’re talking about this, we know we’re not talking about that. In the context of topical parameterization, it is a pre-cursory analysis to winnow out parameters that overlap with each other. Mitigating the potential for that overlap is the core issue when dealing with sets of topical parameters.
In System Engineering, of course, we sometimes deal with the properties that are not physical, some of which might even be unique (or nearly unique) to specific projects. We also deal with multiple instances of the same property on different dingae, in relationships that can be either vertical6 or horizontal (or even both at the same time). In the SE context, the SI list of base properties is not, therefore, “complete”, but we can use it as a template for the wider range of properties required by the SE domain7.
2. Dimensionality
It is important to understand that physics inherently establishes the seven properties of Table 1 to be independent of each other. All possible sums8 and products of the seven, to all possible non-zero exponents, are mutually non-commensurate: we cannot obtain any of the seven by operating with any combination of the others.
That last bit doesn’t mean that these properties don’t interact in the real world. It just means that we can quantify each one without having accidentally quantified any of the others. Mathematics sometimes refers to that notion as “orthogonality“.
Orthogonality implies that the base set of properties of Table 1 can be construed as “dimensions” of a “not-necessarily-Euclidian space” in the sense of abstract mathematics. That would be like talking about a position in 3-D space: x, y, and z can each be supplied with a value absent any influence from the others. No combination of (for example) x and y can force any particular value of z, no matter what exponents they’re raised to, until we point to some particular dingus9. The coordinates correlate only through something that bounds a region (or regions) in the space defined by the dimensions. The dimensions interact only through something that exists in10 the space, not by virtue of the space.
A familiar use of these concepts in Engineering is the practice of “dimensional analysis”, where math operations can be applied to the units11 to determine the dimensionality of the final result12. The SI defines many “derived” quantities in support of that effort, some of which have dedicated units in the system. All derived units can be “algebraically reduced” to powers of the base units.
It is useful to know that the ISO documentation doesn’t claim that the particular set of base properties (Table 1) is the only such set that can be constructed…only that the authorial committee agreed that this is the set they intend for all of us to use as a standard practice, so that we accurately interpret each other’s work13. The choice of this particular set from among the candidate sets was quasi-arbitrary: they picked one that was reasonably familiar to many (possibly most) of the people who would be using the system.
The preceding paragraphs are a bit dense, and are often met with blank stares on the faces of the System Engineering staff when I discuss these concepts14. The important concepts are summarized in Table 2.
| Concept | Description |
| 1 | The elements of the base set address everything the authors needed to talk about |
| 2 | The elements of the base set are mutually independent and, therefore, non-commensurate in any combination |
| 3 | More than one set meeting concepts 1 and 2 was possible |
| 4 | Given concept 3, a familiar set was quasi-arbitrarily selected |
| 5 | The result isn’t perfect, but is adequate if attention is paid to context |
3. Matrix Notation
The notion that an orthogonal set of properties can be used to parameterize a dingus suggests that things like vectors and matrices can express positions and regions in an abstract space of dimensions as described above. Surprisingly15, that notion is consistent with legacy engineering practices.
For example, a manufactured part’s length16 of 6″ will typically be accepted by inspection, where that inspection is required to be accomplished after conditioning the part to within a small variation about (for example) 70ºF17. In effect, the drawing requirement specifies a region in an abstract 2D space comprised of part length and a circumstantial temperature. In addition to drawing callouts and reference to inspection standards, the region can be compactly expressed in several different ways, a sampling of which are shown in Table 3.
| (6±0.01 inch, 70±2ºF) |
| (6±0.01, 70±2)(inch,ºF) |
| (6, 70) ±(0.01, 2) (inch,ºF) |
| ([5.99:6.01], [68:72])(inch,ºF) |
| ((5.99,68):(6.01,72))(inch,ºF) |
All of the expressions in Table 2 are perfectly adequate, provided that the Engineering staff shares a common understanding of the intent.
The ability to formulate properties using matrix notation also suggests that we might be able to arrange a set of topical parameters in tabular form. Tabulation is a useful technique for identifying things that are incomplete which is, in turn, useful for planning their completion. The columns, which might (or might not) be the same for all classes of property, form a data structure.
The applicability of matrix notation further suggests that we might be able to use tensor-valued parameters to concisely identify functional relationships. That concept is deferred to the notion of “measure” in the subsequent discussion.
Aside
The use of matrix notation carries an unfortunate side-effect: most Engineers are accustomed to the implication that the use of matrices implies natural interpretations of things like distance18. In the general case, no such concept is applicable to the spaces that can be described using matrix notation. By extension, it should not be assumed that all standard matrix operations are applicable to parameterization that’s expressed that way.
Structures
Table 4 defines a minimum set of data elements for a master list of base properties to be managed for the project at hand. Such a list might (or might not) be managed across an entire product line, effectively setting the scope for collective management of how basic technical concepts are defined.
| Element Name | Description |
| Nomenclature | A noun-phrase used to identify the base property |
| Position | An ordinal number indicating the position of the base property in subsequently used dimensional vectors. |
| Description | Enough words to succinctly indicate the intended concept. |
| *Source | An array of one or more pointers to the source material causing definition of the base property. |
| Rationale | Summary rationale for declaring the set. |
Table 5 identifies the data elements for a master list of derived (non-base) properties. The dingus-scope of Table 5’s implementation is intended to be the scope of Table 4’s implementation, or some proper sub-scope thereof.
| Element Name | Description |
| Nomenclature | A noun-phrase used to identify the derived property |
| Description | Enough words to succinctly indicate the intended concept. |
| Dimensional Vector | A vector of powers for the derived property: the power to which each base dimension is raised. |
| *Source | An array of one or more pointers to the source material causing definition of the derived property. |
| Rationale | Summary rationale for establishing the derived property. |
Table 5 addresses the notion of a “dimensional vector” to indicate the powers to which each base property is raised in the derivation; the order of those powers in the vector is defined by their order in the base property set (as defined by the implementation of Table 4). For the sake of subsequent convenience (and to avoid the firm requirement for an object-oriented database implementation), the base properties are intended to be instantiated in this table, each having the associated power of 1 (see an m-code example here). In effect, subsequent usage doesn’t care which of the properties of this table’s implementation are base, and which are derived: all are referenced the same way.
Aside
Tables 4 and 5 don’t adhere to the Relational paradigm. Doing so would require the individual dimensions (as defined in the eventual implementation of Table 4) to be hard-coded into the fields of the derived table (Table 5), in which case the “Position” field of Table 4 would not be required. From a database design perspective, that’s absolutely the right thing to do.
From the perspective of operational flexibility, however, it is unreasonably constraining. Hard-coding that material into the database design forces there to be zero entries in the derived table until a final decision is made about the abstract dimensions…essentially meaning that no results can be stored until all the answers are at least conceptually known.
There may be situations where the dimensions are well-fixed before dingus-specific parameters are being defined, in which case hard-coded will result in a significant improvement in both database response and in data integrity.
The elements shown in Table 5 are the key to uniformly managing orthogonality between parameters. The dimensional vector simplifies the identification of potential redundancies. As noted above, not all redundancies of the dimensional vector are errors19 It does, however, provide for immediate screening of such issues.
Having introduced the notion of a dimensional vector, Table 1 from the previous page can be completed as shown in Table 6. Of particular interest is a dimensional array, which is merely an ordered collection of dimensional vectors.
| Element Name | Description |
| *Topic | Pointer to a previously-identified topic |
| Nomenclature | A noun-phrase used to identify the item. |
| Description | Enough words to succinctly indicate the intended concept. |
| *Dimensional Array | An array of pointers to dimensional vectors. |
| *Source | Pointer to the input material leading to definition of the parameter. |
| Rationale | Succinct description of the logic leading to definition. |
A minimum set of data elements for a parameter set can also be defined (see Table 7). Additional elements may prove useful, depending on implementation. It should be noted that validation is necessary to show that the parameters in each set are relevant to the same topic20 . This might require definition of new topics, especially where groups of interacting, interfacing dingae are being parameterized.
| Element Name | Description |
| Nomenclature | A noun-phrase used to identify the set. |
| Description | Enough words to succinctly indicate the intended concept. |
| *Source | An array of one or more pointers to the source material causing definition of the set. |
| Rationale | Summary rationale for declaring the set. |
| *Parameter | An array of one or more pointers to set parameters as defined in Table 6. |
←Back to Part I: Individual Parameters On to Part III: Measures →
Footnotes- That is, neither layer builds upon the other. They address two independent abstract properties.[↩]
- The word was chosen with malice aforethought.[↩]
- Using the formal definition of the term.[↩]
- Which is based on a relative position at a single instant in time[↩]
- which involves a displacement[↩]
- That is, “decomposed”.[↩]
- To the extent possible, it is (of course) very strongly advised that System Engineer’s use the SI concepts.[↩]
- A good argument could be made that these seven should never be added together at all.[↩]
- Which might be tangible, or might not.[↩]
- Formally, we’d say “is defined in”, which admits to the possibility of abstract dingae.[↩]
- more accurately, to the base properties associated with the units[↩]
- …but see the “aside”, above: that’s just mostly true.[↩]
- That is, so that the results are objective.[↩]
- Which is a very rare event![↩]
- Or, perhaps, not.[↩]
- A toleranced dimension in a reference frame defined by the identifying drawing.[↩]
- In this case, “about” means “in the near vicinity of”.[↩]
- That is, they subconsciously interpret the use of vector and matrix notations to imply Euclidian spaces.[↩]
- Unless the implementation chooses to resolve the position/displacement issue identified above.[↩]
- “Validation”, because we’re actually creating a “structural” model when we do this[↩]