- Email: [email protected]
Component interfaces that support measurement uncertainty
Computer Standards & Interfaces 28 (2006) 306 – 310 www.elsevier.com/locate/csi
Component interfaces that support measurement uncertainty B.D. Hall Measurement Standards Laboratory of New Zealand, Industrial Research Ltd., PO Box 31-310, Lower Hutt, New Zealand Available online 24 August 2005
Abstract A method for designing modular instrumentation systems that can propagate measurement uncertainty is described. The approach adheres to current international best-practice in uncertainty calculation, as presented in the bGuide to the Expression of Uncertainty in MeasurementQ [International Organization for Standardization, Geneva, 1995]. System components fully encapsulate implementation details and a standardized interface can be used for inter-module communication. The method offers a convenient conceptual framework for design, providing automatic uncertainty evaluation, as well as simplified testing and validation. D 2005 Elsevier B.V. All rights reserved. Keywords: Measurement uncertainty; Modular instruments; Uncertainty calculation
1. Introduction Internationally accepted guidelines for evaluating measurement uncertainty are provided in the Guide to the Expression of Uncertainty in Measurement (GUM) [1]. However, the GUM’s dLaw of Propagation of UncertaintyT (LPU), which is a general method for combining and propagating uncertainties, is not easy to apply to modern instrumentation. Difficulties arise from the usual expression of the LPU. A single measurement function is assumed that describes the relationship between the values of all influence quantities and a result. Expressions for this function’s partial derivatives are then obtained for use
E-mail address: [email protected]. 0920-5489/$ - see front matter D 2005 Elsevier B.V. All rights reserved. doi:10.1016/j.csi.2005.07.009
in the LPU. In practice, the amount of detail involved in expressing the measurement function and determining these derivatives for instrumentation systems can be prohibitive [2]. An alternative, mathematically equivalent, expression of the LPU provides a more convenient basis for design [3]. This formulation uses a set of functions, representing the intermediate steps of a calculation, which are evaluated iteratively. It can be applied to systems that implement a simple standard interface for inter-module exchange of information. The design approach is very effective. It cleanly isolates module implementation details from generic system algorithms and extends current conceptual design practices by supporting uncertainty calculations in an unobtrusive and intuitive manner. Validation and testing can be simplified because module
B.D. Hall / Computer Standards & Interfaces 28 (2006) 306–310
functionality is decoupled from system algorithms, allowing independent testing of components. Reuse of components also becomes feasible. This paper briefly describes the new LPU algorithm in Section 2 and then explains how to apply the approach to designs in Section 3. Section 4 discusses the advantages of the technique and refers to some recent applications.
2. Mathematical overview Following the GUM, measurement of a quantity can be represented by a function xm ¼ f ðx1 ; : : : ; xl Þ;
ð1Þ
where the input values, x 1, . . ., x l are subject to uncertainty so there is also uncertainty in the result, x m . Quite generally, Eq. (1) can be evaluated in a series of intermediate steps, involving simpler functions. So, by associating a label j with each step, there will be a function f j taking a set of inputs Kj that returns a value xj . We shall refer to these steps as modules, and to the set of steps associated with the evaluation of f as a system. This terminology is convenient in the context of instrumentation systems. For a system composed of m modules, the output, x m , can be found by evaluating Eq. (2), iteratively, for j = 1, . . ., m (Kj may include values obtained from earlier steps)1 xj ¼ fj Kj :
ð2Þ
The standard uncertainty in a result2, u(x m ), can be found using the LPU [1] " uð x m Þ ¼
l X
l X
#1=2 uh ðxm Þ rhi ui ðxm Þ
;
ð3Þ
307
in which r hi is a coefficient of correlation between inputs h and i.3 The u i (x m ) terms are related to the sensitivity of x m to small changes in the value of x i . They are referred to as components of uncertainty and defined as ui ð x m Þ ¼
Bf uðxi Þ: Bxi
ð4Þ
Note that the notion of a component of uncertainty can apply to the output of any module, so f above may be replaced by any f j .4 Again, it is possible to calculate the components of uncertainty in x m iteratively. For a particular choice of i, u i (xm ) can be found by evaluating Eq. (5), for j = 1, . . ., m, X Bfj ui x j ¼ ui ðxk Þ: Bxk x aK k
ð5Þ
j
This is more convenient than Eq. (4) because the calculation is expressed in terms of the partial derivatives of the module function, f j , which is only differentiated with respect to the direct module inputs, the xk a Kj. Eqs. (2) and (5) are key results. They give an alternative view of measurement uncertainty calculations, which explicitly recognizes modularity. These equations can be used to establish mathematical requirements for the design of modular components. A system comprised of such components will be inherently capable of propagating uncertainty using the LPU.
3. Systems overview Two attributes, essential to the calculation of uncertainty, have been associated with modules: ! a value function, f j , returning x j ; ! a component of uncertainty function, returning u i (x j ).
h¼1 i¼1 3
1
To ensure the correct order of evaluation, subscripts are assigned so that j N k, where x k is any member of the set Kj . 2 The standard uncertainty of a quantity, x is written as u(x).
For clarity, subscripts h and i are only used in the text to refer to system inputs, while j and k can refer to any modules, including system inputs. 4 In this notation u i (x i ) u u(x i ).
308
B.D. Hall / Computer Standards & Interfaces 28 (2006) 306–310
We now consider a standard interface for inter-module communication. It has become common practice, in instrumentation systems, to standardize the communications interface between system components. In effect, this allows Eq. (2) to be evaluated in a simple and intuitive manner.5 At the same time, it gives designers increased flexibility and choice with regard to system components. To support the evaluation of Eq. (5), another interface function is needed.6 This function returns the component of uncertainty value u i (x j ), pertaining to the module j. It is convenient to distinguish modules associated with system inputs (i = 1, . . ., l) from other system modules. For example, Eq. (3) sums over all inputs. To support summation, we include one more interface function that, for a module j, returns an iterable set of references to the system inputs on which j depends. That is, references to those inputs from among i = 1, . . ., l which contribute, in some way, to the value of x j . Fig. 1 shows a Unified Modelling Language (UML) [4] representation of a standard interface for modules, comprising three member functions. Two classes are shown in the figure: Uncertain is a generic interface for all modules and Input is a refinement for system inputs only. The member functions value and uComponent evaluate f j and u i (x j ), respectively. The argument i to uComponent refers to an object of type Input. The function dependsOn returns a set of references to the Input objects on which the module depends. By standardizing the module interface, the task of implementing uncertainty calculations is neatly divided between system-level implementation of Eq. (3) and module-level implementation of the Uncertain, and Input, interfaces. 3.1. Module design Module design is governed by specific module functionality. For example, suppose a module multiplies the outputs of two other (arbitrary) modules. 5 The iteration order, for j = 1 to m, is achieved naturally by the sequencing of calls to component value functions. 6 The same sequencing of function calls takes care of the iteration order.
«Interface» Uncertain value() : Float uComponent( i : Input ) : Float dependsOn() : Set of Input
Input
Fig. 1. A UML class diagram for a standard module interface called Uncertain and a refinement of it called Input, which is used only for system inputs.
Labelling the direct inputs as dleftT and drightT, the module function can be written as xj ¼ fj xleft ; xright ¼ xleft xright and the component of uncertainty function can be found by substituting expressions for the two partial derivatives of this function in Eq. (5) ui xj ¼ xright ui ðxleft Þ þ xleft ui xright : Implementation of the standard interface is straightforward in terms of these two expressions. Fig. 2 sketches out a pseudo-code solution. Note that no assumptions are made about the nature of the left and right modules, other than support for the Uncertain interface. Note also that the component of uncertainty calculation is handled by combining the module function’s partial derivatives with the left and right argument component of uncertainty values. The implementation of dependsOn combines the collections returned by the left and right argument modules, and removes any duplicate elements from the union. This implementation is suitable for any binary mathematical operation (e.g., addition, subtraction, division, y x , etc.). 3.2. System design The standard uncertainty should be evaluated, according to Eq. (3), by a system-level routine that makes calls to the standard interface of a module to obtain the input set and the components of uncertainty. Fig. 3 suggests an implementation, assuming a
B.D. Hall / Computer Standards & Interfaces 28 (2006) 306–310
309
value() { return left.value() * right.value() } uComponent(i : Input) { return right.value() * left.uComponent(i) + left.value() * right.uComponent(i) } dependsOn() { return uniqueUnion( left.dependsOn(), right.dependsOn() ) } Fig. 2. Pseudo-code for functions implementing the Uncertain interface of a multiplication module. The uniqueUnion function combines all the elements contained in its arguments and eliminates duplicates.
suitable collection type SetOfInput that can be iterated over. Note that the correlation coefficients, r hi will also be managed at the system level. Nothing in the implementation in Fig. 3 is specific to the measurement associated with x. The routine merely uses the attributes of the Uncertain interface to obtain the standard uncertainty value. As a consequence, this routine is a suitable template for any type of system measurement. 3.3. Input modules Input modules need more attributes than the system modules involved in processing measurement data, which is why a special interface has been indicated. In particular, the GUM associates a numerical value called the ddegrees of freedomT with an input and provides an equation for determining an deffectiveT number of degrees in any result. The effective degrees of freedom is a parameter used to formulate statements about the uncertainty in a result. In terms of system design, the effective degrees of freedom calculation7 is also a system-level function. It involves summation over a set of inputs and requires an extended input interface that exposes the degrees of freedom attribute. 4. Discussion The approach outlined above fully encapsulates implementation details about a measurement procedure inside modules. This has a number of consequences. 7
Often referred to as the dWelch–SatterthwaiteT formula.
First, because modules are essentially independent units using standard interfaces, design and testing can be carried out independently and there is enhanced potential for module reuse. These are characteristics generally expected of modern instrumentation, however, until now, full support for uncertainty has not been possible. Second, the uncertainty calculation capability is transparent. So, for example, a particular system design could be realized using different components with different performance specifications and, in every case, the uncertainty will be correctly evaluated. In other terms, dynamic interchange of modules can be supported (i.e., plug-and-play) and a system uncertainty will always be evaluated for the current configuration. Third, systems are inherently extensible. Any module can be linked with a further network of modules. Or, in other terms, any result can be incorporated into further calculations. The design technique supports the view of a measurement system as performing an arbitrary number of intermediate steps. These aspects of the technique are features of software libraries developed using the design technique [5]. The libraries introduce a new abstract data type, called an uncertain number, which is the software equivalent of a module. The abstraction combines value and uncertainty attributes in a single entity, representing a measured value. Measurement functions can be expressed in an arbitrary number of convenient steps, which is a natural programming idiom. Uncertain number software largely eliminates the complexity of uncertainty calculations because the details are automated by library modules and system routines.
310
B.D. Hall / Computer Standards & Interfaces 28 (2006) 306–310
uncertainty(x : Uncertain) { sum : Float inputs : SetOfInputs sum = 0.0 inputs = x.dependsOn() for h in inputs { for i in inputs { sum = sum + x.uComponent(h) * r(h,i) * x.uComponent(i) } } return sum } Fig. 3. Pseudo-code for implementation of Eq. (3) using the Uncertain interface. It is assumed that r(h, i) returns the value r hi .
The technique has been used to develop several applications that involve data acquisition and subsequent data processing [6–8]. Software models of instrument uncertainty are used to transform raw data into uncertain numbers, which can then be processed using mathematical operations provided by a library. These applications are successful prototypes of measurement systems with full support for measurement uncertainty.
5. Conclusions A technique for modular system design has been presented that fully supports the general method of uncertainty calculation described in the GUM. The technique is simple to apply. It allows full encapsulation of calculation details within modules, so that generic system-level routines can work with standard communications interfaces. The method has the potential to enhance system functionality without adding a burden of increased complexity. Testing and validation of modules, and system algorithms, can be streamlined and reuse of modular components is feasible.
References [1] ISO: Guide to the Expression of Uncertainty in Measurement, 2nd edition, International Organization for Standardization, Geneva, 1995.
[2] B. Anderson, Keynote Address, NCSL International Workshop and Symposium, (Washington, DC, July), (see) http:// metrologyforum.tm.agilent.com/ncsli2001.shtml, 2001. [3] B.D. Hall, The GUM-Tree design pattern for uncertainty software, in: P. Ciarlini, M.G. Cox, F. Pavese, G.B. Rossi (Eds.), Advanced Mathematical and Computational Tools in Metrology VI, World Scientific, Singapore, 2004, pp. 199 – 208. [4] G. Booch, J. Rumbaugh, I. Jacobson, The Unified Modeling Language User Guide, Addison-Wesley, 1999. [5] Further information is available at http://www.irl.cri.nz/msl/mst/. [6] B.D. Hall, Automatic Calculation of Measurement Uncertainty, (Proc. NCSLI Workshop and Symposium, Salt Lake City), 2004. [7] B.D. Hall, M. Rodriguez, The Uncertainty of the dDirect MethodT of Measuring the Equivalent Source Mismatch of a Power Splitter, (Industrial Research Ltd., Report 1574, May), 2004. [8] B.D. Hall, Propagation of uncertainty in modular measurement systems, Proc. Int. Workshop on Advanced Methods for Uncertainty Estimation in Measurement (Niagara Falls, Canada, 13 May, 2005). Blair Hall is a senior research scientist at the Measurement Standards Laboratory of New Zealand (MSL) working in the area of RF and microwave standards. Before joining MSL, Dr Hall lecturered in Physics and Electronics at Massey University and earlier held a postdoctoral position at the Swiss Federal Office of Metrology (METAS) in Bern. Dr Hall holds a Dr. e`s Sci. from the Ecole Polytechnique Fe´de´rale de Lausanne (EPFL).
Component interfaces that support measurement uncertainty B.D. Hall Measurement Standards Laboratory of New Zealand, Industrial Research Ltd., PO Box 31-310, Lower Hutt, New Zealand Available online 24 August 2005
Abstract A method for designing modular instrumentation systems that can propagate measurement uncertainty is described. The approach adheres to current international best-practice in uncertainty calculation, as presented in the bGuide to the Expression of Uncertainty in MeasurementQ [International Organization for Standardization, Geneva, 1995]. System components fully encapsulate implementation details and a standardized interface can be used for inter-module communication. The method offers a convenient conceptual framework for design, providing automatic uncertainty evaluation, as well as simplified testing and validation. D 2005 Elsevier B.V. All rights reserved. Keywords: Measurement uncertainty; Modular instruments; Uncertainty calculation
1. Introduction Internationally accepted guidelines for evaluating measurement uncertainty are provided in the Guide to the Expression of Uncertainty in Measurement (GUM) [1]. However, the GUM’s dLaw of Propagation of UncertaintyT (LPU), which is a general method for combining and propagating uncertainties, is not easy to apply to modern instrumentation. Difficulties arise from the usual expression of the LPU. A single measurement function is assumed that describes the relationship between the values of all influence quantities and a result. Expressions for this function’s partial derivatives are then obtained for use
E-mail address: [email protected]. 0920-5489/$ - see front matter D 2005 Elsevier B.V. All rights reserved. doi:10.1016/j.csi.2005.07.009
in the LPU. In practice, the amount of detail involved in expressing the measurement function and determining these derivatives for instrumentation systems can be prohibitive [2]. An alternative, mathematically equivalent, expression of the LPU provides a more convenient basis for design [3]. This formulation uses a set of functions, representing the intermediate steps of a calculation, which are evaluated iteratively. It can be applied to systems that implement a simple standard interface for inter-module exchange of information. The design approach is very effective. It cleanly isolates module implementation details from generic system algorithms and extends current conceptual design practices by supporting uncertainty calculations in an unobtrusive and intuitive manner. Validation and testing can be simplified because module
B.D. Hall / Computer Standards & Interfaces 28 (2006) 306–310
functionality is decoupled from system algorithms, allowing independent testing of components. Reuse of components also becomes feasible. This paper briefly describes the new LPU algorithm in Section 2 and then explains how to apply the approach to designs in Section 3. Section 4 discusses the advantages of the technique and refers to some recent applications.
2. Mathematical overview Following the GUM, measurement of a quantity can be represented by a function xm ¼ f ðx1 ; : : : ; xl Þ;
ð1Þ
where the input values, x 1, . . ., x l are subject to uncertainty so there is also uncertainty in the result, x m . Quite generally, Eq. (1) can be evaluated in a series of intermediate steps, involving simpler functions. So, by associating a label j with each step, there will be a function f j taking a set of inputs Kj that returns a value xj . We shall refer to these steps as modules, and to the set of steps associated with the evaluation of f as a system. This terminology is convenient in the context of instrumentation systems. For a system composed of m modules, the output, x m , can be found by evaluating Eq. (2), iteratively, for j = 1, . . ., m (Kj may include values obtained from earlier steps)1 xj ¼ fj Kj :
ð2Þ
The standard uncertainty in a result2, u(x m ), can be found using the LPU [1] " uð x m Þ ¼
l X
l X
#1=2 uh ðxm Þ rhi ui ðxm Þ
;
ð3Þ
307
in which r hi is a coefficient of correlation between inputs h and i.3 The u i (x m ) terms are related to the sensitivity of x m to small changes in the value of x i . They are referred to as components of uncertainty and defined as ui ð x m Þ ¼
Bf uðxi Þ: Bxi
ð4Þ
Note that the notion of a component of uncertainty can apply to the output of any module, so f above may be replaced by any f j .4 Again, it is possible to calculate the components of uncertainty in x m iteratively. For a particular choice of i, u i (xm ) can be found by evaluating Eq. (5), for j = 1, . . ., m, X Bfj ui x j ¼ ui ðxk Þ: Bxk x aK k
ð5Þ
j
This is more convenient than Eq. (4) because the calculation is expressed in terms of the partial derivatives of the module function, f j , which is only differentiated with respect to the direct module inputs, the xk a Kj. Eqs. (2) and (5) are key results. They give an alternative view of measurement uncertainty calculations, which explicitly recognizes modularity. These equations can be used to establish mathematical requirements for the design of modular components. A system comprised of such components will be inherently capable of propagating uncertainty using the LPU.
3. Systems overview Two attributes, essential to the calculation of uncertainty, have been associated with modules: ! a value function, f j , returning x j ; ! a component of uncertainty function, returning u i (x j ).
h¼1 i¼1 3
1
To ensure the correct order of evaluation, subscripts are assigned so that j N k, where x k is any member of the set Kj . 2 The standard uncertainty of a quantity, x is written as u(x).
For clarity, subscripts h and i are only used in the text to refer to system inputs, while j and k can refer to any modules, including system inputs. 4 In this notation u i (x i ) u u(x i ).
308
B.D. Hall / Computer Standards & Interfaces 28 (2006) 306–310
We now consider a standard interface for inter-module communication. It has become common practice, in instrumentation systems, to standardize the communications interface between system components. In effect, this allows Eq. (2) to be evaluated in a simple and intuitive manner.5 At the same time, it gives designers increased flexibility and choice with regard to system components. To support the evaluation of Eq. (5), another interface function is needed.6 This function returns the component of uncertainty value u i (x j ), pertaining to the module j. It is convenient to distinguish modules associated with system inputs (i = 1, . . ., l) from other system modules. For example, Eq. (3) sums over all inputs. To support summation, we include one more interface function that, for a module j, returns an iterable set of references to the system inputs on which j depends. That is, references to those inputs from among i = 1, . . ., l which contribute, in some way, to the value of x j . Fig. 1 shows a Unified Modelling Language (UML) [4] representation of a standard interface for modules, comprising three member functions. Two classes are shown in the figure: Uncertain is a generic interface for all modules and Input is a refinement for system inputs only. The member functions value and uComponent evaluate f j and u i (x j ), respectively. The argument i to uComponent refers to an object of type Input. The function dependsOn returns a set of references to the Input objects on which the module depends. By standardizing the module interface, the task of implementing uncertainty calculations is neatly divided between system-level implementation of Eq. (3) and module-level implementation of the Uncertain, and Input, interfaces. 3.1. Module design Module design is governed by specific module functionality. For example, suppose a module multiplies the outputs of two other (arbitrary) modules. 5 The iteration order, for j = 1 to m, is achieved naturally by the sequencing of calls to component value functions. 6 The same sequencing of function calls takes care of the iteration order.
«Interface» Uncertain value() : Float uComponent( i : Input ) : Float dependsOn() : Set of Input
Input
Fig. 1. A UML class diagram for a standard module interface called Uncertain and a refinement of it called Input, which is used only for system inputs.
Labelling the direct inputs as dleftT and drightT, the module function can be written as xj ¼ fj xleft ; xright ¼ xleft xright and the component of uncertainty function can be found by substituting expressions for the two partial derivatives of this function in Eq. (5) ui xj ¼ xright ui ðxleft Þ þ xleft ui xright : Implementation of the standard interface is straightforward in terms of these two expressions. Fig. 2 sketches out a pseudo-code solution. Note that no assumptions are made about the nature of the left and right modules, other than support for the Uncertain interface. Note also that the component of uncertainty calculation is handled by combining the module function’s partial derivatives with the left and right argument component of uncertainty values. The implementation of dependsOn combines the collections returned by the left and right argument modules, and removes any duplicate elements from the union. This implementation is suitable for any binary mathematical operation (e.g., addition, subtraction, division, y x , etc.). 3.2. System design The standard uncertainty should be evaluated, according to Eq. (3), by a system-level routine that makes calls to the standard interface of a module to obtain the input set and the components of uncertainty. Fig. 3 suggests an implementation, assuming a
B.D. Hall / Computer Standards & Interfaces 28 (2006) 306–310
309
value() { return left.value() * right.value() } uComponent(i : Input) { return right.value() * left.uComponent(i) + left.value() * right.uComponent(i) } dependsOn() { return uniqueUnion( left.dependsOn(), right.dependsOn() ) } Fig. 2. Pseudo-code for functions implementing the Uncertain interface of a multiplication module. The uniqueUnion function combines all the elements contained in its arguments and eliminates duplicates.
suitable collection type SetOfInput that can be iterated over. Note that the correlation coefficients, r hi will also be managed at the system level. Nothing in the implementation in Fig. 3 is specific to the measurement associated with x. The routine merely uses the attributes of the Uncertain interface to obtain the standard uncertainty value. As a consequence, this routine is a suitable template for any type of system measurement. 3.3. Input modules Input modules need more attributes than the system modules involved in processing measurement data, which is why a special interface has been indicated. In particular, the GUM associates a numerical value called the ddegrees of freedomT with an input and provides an equation for determining an deffectiveT number of degrees in any result. The effective degrees of freedom is a parameter used to formulate statements about the uncertainty in a result. In terms of system design, the effective degrees of freedom calculation7 is also a system-level function. It involves summation over a set of inputs and requires an extended input interface that exposes the degrees of freedom attribute. 4. Discussion The approach outlined above fully encapsulates implementation details about a measurement procedure inside modules. This has a number of consequences. 7
Often referred to as the dWelch–SatterthwaiteT formula.
First, because modules are essentially independent units using standard interfaces, design and testing can be carried out independently and there is enhanced potential for module reuse. These are characteristics generally expected of modern instrumentation, however, until now, full support for uncertainty has not been possible. Second, the uncertainty calculation capability is transparent. So, for example, a particular system design could be realized using different components with different performance specifications and, in every case, the uncertainty will be correctly evaluated. In other terms, dynamic interchange of modules can be supported (i.e., plug-and-play) and a system uncertainty will always be evaluated for the current configuration. Third, systems are inherently extensible. Any module can be linked with a further network of modules. Or, in other terms, any result can be incorporated into further calculations. The design technique supports the view of a measurement system as performing an arbitrary number of intermediate steps. These aspects of the technique are features of software libraries developed using the design technique [5]. The libraries introduce a new abstract data type, called an uncertain number, which is the software equivalent of a module. The abstraction combines value and uncertainty attributes in a single entity, representing a measured value. Measurement functions can be expressed in an arbitrary number of convenient steps, which is a natural programming idiom. Uncertain number software largely eliminates the complexity of uncertainty calculations because the details are automated by library modules and system routines.
310
B.D. Hall / Computer Standards & Interfaces 28 (2006) 306–310
uncertainty(x : Uncertain) { sum : Float inputs : SetOfInputs sum = 0.0 inputs = x.dependsOn() for h in inputs { for i in inputs { sum = sum + x.uComponent(h) * r(h,i) * x.uComponent(i) } } return sum } Fig. 3. Pseudo-code for implementation of Eq. (3) using the Uncertain interface. It is assumed that r(h, i) returns the value r hi .
The technique has been used to develop several applications that involve data acquisition and subsequent data processing [6–8]. Software models of instrument uncertainty are used to transform raw data into uncertain numbers, which can then be processed using mathematical operations provided by a library. These applications are successful prototypes of measurement systems with full support for measurement uncertainty.
5. Conclusions A technique for modular system design has been presented that fully supports the general method of uncertainty calculation described in the GUM. The technique is simple to apply. It allows full encapsulation of calculation details within modules, so that generic system-level routines can work with standard communications interfaces. The method has the potential to enhance system functionality without adding a burden of increased complexity. Testing and validation of modules, and system algorithms, can be streamlined and reuse of modular components is feasible.
References [1] ISO: Guide to the Expression of Uncertainty in Measurement, 2nd edition, International Organization for Standardization, Geneva, 1995.
[2] B. Anderson, Keynote Address, NCSL International Workshop and Symposium, (Washington, DC, July), (see) http:// metrologyforum.tm.agilent.com/ncsli2001.shtml, 2001. [3] B.D. Hall, The GUM-Tree design pattern for uncertainty software, in: P. Ciarlini, M.G. Cox, F. Pavese, G.B. Rossi (Eds.), Advanced Mathematical and Computational Tools in Metrology VI, World Scientific, Singapore, 2004, pp. 199 – 208. [4] G. Booch, J. Rumbaugh, I. Jacobson, The Unified Modeling Language User Guide, Addison-Wesley, 1999. [5] Further information is available at http://www.irl.cri.nz/msl/mst/. [6] B.D. Hall, Automatic Calculation of Measurement Uncertainty, (Proc. NCSLI Workshop and Symposium, Salt Lake City), 2004. [7] B.D. Hall, M. Rodriguez, The Uncertainty of the dDirect MethodT of Measuring the Equivalent Source Mismatch of a Power Splitter, (Industrial Research Ltd., Report 1574, May), 2004. [8] B.D. Hall, Propagation of uncertainty in modular measurement systems, Proc. Int. Workshop on Advanced Methods for Uncertainty Estimation in Measurement (Niagara Falls, Canada, 13 May, 2005). Blair Hall is a senior research scientist at the Measurement Standards Laboratory of New Zealand (MSL) working in the area of RF and microwave standards. Before joining MSL, Dr Hall lecturered in Physics and Electronics at Massey University and earlier held a postdoctoral position at the Swiss Federal Office of Metrology (METAS) in Bern. Dr Hall holds a Dr. e`s Sci. from the Ecole Polytechnique Fe´de´rale de Lausanne (EPFL).