In this post, we will explore the mathematical significance of a measurand.

SAE AS6969™ follows JCGM 100 in defining a measurand as a particular quantity subject to measurement. In the Unified Modeling Language (UML) we would express a measurand in the form ‘Aircraft:: grossWeight: Mass’ where ‘Aircraft’ is a type that owns the property of ‘grossWeight: Mass’ where ‘Mass’ is the property type and ‘grossWeight’ is the property name. In UML, it is conventional to express a value property as an attribute, although it could also be expressed as an association end.

We can think of a UML type as the specification for a set of instances of that type, where the properties of the type form the specification. Strictly speaking, these would be locally small sets, as in practice we can assume the instances are countable (the system has finite memory).

In Predicate Logic we could express our measurand as the formula ‘mass = grossWeight(aircraft)’ where the argument denotes the subject (any instance of the Aircraft type) and the output is the value (any instance of the Mass type).

This points to the treatment of a measurand as a mathematical function. In higher mathematics we may write a function as f:X→Y, where X is the domain – the set of all possible instances of the function input – and Y is the codomain – the set of all possible instances of the function output. In ordinary mathematics we may write y = f(x).

In our measurand example, the domain is the Aircraft type whose possible instances are a₁, a₂… and the codomain is the Mass type whose possible instances (values) are m₁, m₂…  Thus, in general, we can think of a property name as denoting a function that maps its domain (its owning type) to its codomain (its property type).

So far, we have skipped the value structure of property type. For example, does the number part of the mass value represent so many kilograms or pounds? We tend to regard ‘Mass (kg)’ and ‘Mass (lb)’ as logical realizations of the conceptual ‘Mass’ property type, where mass is an innate quantity in the physical world and kilogram and pound weight are scientifically arbitrary references.  The logical measurand would therefore be ‘Aircraft:: grossWeight: Mass (kg)’ for example, or ‘mass (kg) = grossWeight(aircraft)’. Here we have preserved the idea that the value of mass is the magnitude of mass, which is different from the number part of the value held in a UML attribute slot. It would not be useful to define the codomain as simply a range cardinal numbers.

It is important to note that the root of our concept of mass is the generalization ‘PhysicalBody:: massProperty: Mass’. We could specialize the owning type to give ‘Aircraft:: massProperty: Mass’, however we have multiple measurands of the aircraft mass property, including empty weight, operational empty weight, gross weight, gross takeoff weight, and gross landing weight. Therefore there are multiple mappings from the Aircraft domain to the Mass codomain. This would appear more pragmatic than defining a specific codomain for aircraft mass properties containing every aircraft mass property within that codomain. Although this is a syntactic choice.

SAE AS6969™, in accordance with JCGM 100, defines a ‘measurement’ (in contrast to a ‘measurand’) as the set of operations having the object of determining a value of a quantity. In the Data Dictionary, a measurement table contains a series of epistemological refinements on a measurand specification. The sequence is ‘measurand’ → ‘measurement principle’ → ‘measurement method’ → ‘measurement procedure’, where the required detail depends on the project.

Consider the measurand ‘Aircraft:: altitude: EllipsoidalHeight’ where the measurement principle could be barometric height, the measurement method could be the U.S. Standard Atmosphere (USSA) 1976 model, and the measurement procedure could specify a particular instrument type. Therefore this would be the epistemological progression:

Aircraft:: altitude: EllipsoidalHeight

Aircraft:: barometricHeight: EllipsoidalHeight

Aircraft:: barometricHeightUSSA1976: EllipsoidalHeight

Aircraft:: altimeterReading: EllipsoidalHeight

Note that in all of these statements the domain and codomain are unchanged.

The function concept is convenient when modeling a control input. Consider SAE JAUS, which has the notion of ‘effort’. Effort is a control input, from 0 to 100%, that can be applied to any system to which the operator control unit has been paired. We can model such a system as y = f(x, a) where y and ‘a’ are function-specific quantities and x is a parameter (control input) of the function. The function can be described to make the control input dimensionless (i.e. digital).

System:: effort: Control (percent)

Similarly, a function coefficient can be modeled. For example transducer gain or sensitivity. In principle, a coefficient could have any dimension equation and therefore units. To avoid a proliferation of off-system units for one-off applications, it might be desirable to either normalize the coefficient in the description of the function or create a separate list of domain-specfic coefficient types that is distinct from common quantity types and units.

This post was updated thanks to comments by Jim Albers of Fastpilot, Inc.