Quantity Checking through Unit of Measurement Libraries, Current

Status and Future Directions

Steve McKeever, G

orkem Pac¸aci and Oscar Bennich-Bj

orkman

Department of Informatics and Media, Uppsala University, Sweden

Keywords:

Units of Measurement, Units Checking, Unit Libraries, Quantity Pattern.

Abstract:

Unit errors are known to have caused some costly software engineering disasters, most notably the Mars

Climate Orbiter back in 1999. As unit annotations are not mandatory for execution only dramatic events

become newsworthy. Anecdotally however, there is evidence to suggest that these kinds of errors are recurrent

and under-reported. There are an abundance of tools and most notably libraries to aid scientiﬁc developers

manage unit deﬁnitions. In this paper we look in detail at how a number of prominent libraries in the most

popular programming languages support units. We argue that even when these libraries are based on a sound

design pattern, their implementation becomes too broad. Each library is distinct with varying features, lacking

a core API, compromising both interoperability and thereby usage. We claim that further library or tool

development is not needed to further adoption, but that a greater understanding of developers requirements is.

1 INTRODUCTION

In scientiﬁc applications, physical quantities and units

of measurement are used regularly. However few pro-

gramming languages provide direct support for man-

aging them. The technical deﬁnition of a physical

quantity is a “property of a phenomenon, body, or

substance, where the property has a magnitude that

can be expressed as a number and a reference” (Joint

Committee for Guides in Metrology (JCGM), 2012).

To explain this further, each quantity is declared as

a number (the magnitude of the quantity) with an

associated unit (Bureau International des Poids et

Mesures, 2014). For example you could assert the

physical quantity of length with the unit metre and

the magnitude 10 (10m). However, the same length

can also be expressed using other units such as cen-

timetres or kilometres, at the same time changing the

magnitude (1000cm or 0.01km). Although these ex-

amples are all based on the International System of

Units (SI), which is the most used and well known

unit system, there exists several other systems that

these physical quantities can be expressed in, each

with different units for the same quantity. Other ex-

amples include the Imperial system, the Atomic Units

system, and the CGS (centimetre, gram, second) sys-

tem. These have evolved over time and branched off

from each other.

Some well known and expensive errors have

arisen due to unit inconsistencies when operating over

values of differing unit systems or differing represen-

tations of dimensions. The most famous of which is

the Mars Climate Orbiter (Stephenson et al., 1999).

The orbiter had malfunctioned, causing it to disinte-

grate in the upper atmosphere. A later investigation

found that the root cause of the crash was the incor-

rect usage of Imperial units in the probe’s software.

However for the most part, scientiﬁc developers have

been able to manage their code without tool or static

checking support. The burden of cost for such errors

has been contained within the scope of their endeav-

ours.

Several popular software modelling languages in-

clude representations of physical units, such as Mod-

elica (Modelica, 2018) or VSL in the MARTE stan-

dard (Ribeiro et al., 2016), but these form part of

the speciﬁcation and are not a requirement for de-

rived executables, much as cardinality annotations in

UML diagrams. With greater interoperability, indus-

trial use of computational simulations and penetra-

tion of digitalisation through cyber-physical systems;

it seems pertinent to faithfully represent key proper-

ties of physical systems such as units of measurement

in code bases. This can be achieved through the use of

domain speciﬁc languages (Garny et al., 2008) or pro-

gramming languages that support units of measure-

ment, tools that detect unit inconsistencies or libraries

that provide units to existing languages.

McKeever, S., Paçaci, G. and Bennich-Björkman, O.

Quantity Checking through Unit of Measurement Libraries, Current Status and Future Directions.

DOI: 10.5220/0007524704410447

In Proceedings of the 7th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2019), pages 441-447

ISBN: 978-989-758-358-2

 2019 by SCITEPRESS – Science and Technology Publications, Lda. All r ights reserved

441

Adding units to conventional programming lan-

guages has a rich history going back to the 1970s and

early 80s, with proposals to extend Fortran (Gehani,

1977) and then Pascal (Dreiheller et al., 1986). The

pioneering foundational work was undertaken by

Wand and O’Keefe (Wand and O’Keefe, 1991). They

revealed how to add dimensions to the simply-typed

lambda calculus, such that polymorphic dimensions

can be inferred in a way that is a natural extension of

Milner’s polymorphic type inference algorithm.

In terms of initial library support for modular or

object-oriented languages, Hilﬁnger (Hilﬁnger, 1988)

showed how to exploit Ada’s abstraction facilities,

namely operator overloading and type parameterisa-

tion, to assign attributes for units of measurement to

variables and values.

All of the aforementioned solutions require ei-

ther migration to a new language or annotating the

source code, both of which are burdens on the de-

velopers. A more lightweight methodology is pre-

sented in (Ore et al., 2017) that uses an initial pass to

build a mapping from attributes in shared libraries to

units. The shared libraries contain unit speciﬁcations

so this mapping is used to propagate into a source pro-

gramme and, as the authors show, detect inconsisten-

cies.

An alternative pathway is to introduce physi-

cal units into an object oriented modelling platform,

along with a compilation workﬂow that leverages

OCL expressions (Mayerhofer et al., 2016) or staged

computation (Allen et al., 2004) to derive units where

possible at compile-time. These elegant abstractions

lift the declaration and management of units into soft-

ware models but do not solve the interoperability

problem due to the lack of agreed conventions for

scientiﬁc, medical and ﬁnancial applications of the

Quantity pattern.

Unfortunately we lack an authoritative estimate

of how frequently unit inconsistencies occur or their

cost. Anecdotally we can glean that it is not negli-

gible from experiments described in certain papers.

Cooper (Cooper and McKeever, 2008) developed a

validation tool for CellML, a domain speciﬁc lan-

guage for modelling biological systems. He applied

it to the repository of CellML models and, of those

that were found to be invalid, 60% had dimension-

ally inconsistent units. Similarly, the Osprey type

system type system (Jiang and Su, 2006) provides

an advanced unit checker and inference engine for

C. In their paper they describe having applied it to

mature scientiﬁc application code and found hitherto

unknown errors. Unfortunately they do not describe

the prevalence or magnitude of these errors. A more

telling statistic is found in (Ore et al., 2017) where

they apply their lightweight unit inconsistency tool to

213 open-source systems, ﬁnding inconsistencies in

11% of them.

There are many libraries that provide support for

units in all of the popular programming languages.

However no standard has emerged. In this paper we

argue that the existing design pattern is too broad and

open to interpretation. The rest of this paper is struc-

tured as follows. In Section 2 we provide an introduc-

tion to units of measurement and the Quantity pattern

that provides a standard object oriented solution. In

Section 3 we describe the underlying implementation

strategy of some of the most used unit libraries in the

most popular programming languages. In Section 4

we surmise as to why the Quantity pattern has failed

to galvanise the scientiﬁc programming community,

and suggest areas of future work required to promote

better software engineering with regards to units of

measurement. Finally in Section 5 we articulate our

position and contextualise our study further.

2 DESCRIBING UNITS OF

MEASUREMENT

Here, we will ﬁrst introduce the problem by means of

an example scenario. Two programmers are working

on a system that manages physical quantities using a

popular language such as C#, Java, or Python. The

ﬁrst programmer wants to create two quantities that

will be used by the second at a later stage. Because

the language does not have support for this type of

construct, he or she decides to do it using integers and

adding comments, like this:

int mass = 10; // in tonnes

int acceleration = 10; // in m.sˆ-2

Now the second programmer wants to use these val-

ues to calculate force using the well-known equation

F = m × a:

int force = mass * acceleration; // 100N

The variable force will now have the value of 100,

assumed to be 100 N. The issue is that the vari-

able mass is actually representing 10 tonnes, not

10 kilograms. This means that the actual value of

the force should be 100000 N (instead of 100 N), off

by a factor of one thousand. Because the quantities

in this example are represented using integers there is

no way for the compiler to know this information and

therefore it is up to the programmers themselves to

keep track of it.

The only reliable way to solve this is try to remove

the human element by having a systematic means

of checking the units of calculations to ensure that

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

442

they are handled correctly. This type of automatic

check is potentially something that could be under-

taken at compile time in a strongly typed language,

but unfortunately very few languages have support for

units of measurement and only one of those is in the

top twenty most popular programming languages, ac-

cording to the TIOBE index (TIOBE, 2018). In all

other languages, it is up to the software developers to

create these checks themselves.

One example of how this can be achieved is to

make sure the compiler knows what quantities are

being used by encapsulating this into a class hierar-

chy, with each unit having its own class. The scenario

above would then look like this instead:

Tonne mass = 10;

Acceleration acceleration = 10; // in m.sˆ-2

Force force = mass * acceleration; // 100000N

Compared to the previous example, here the com-

piler now knows exactly what it is dealing with and

thus the information that the mass is in tonnes is kept

intact and the correct force can be calculated in the

end. This type of solution not only means that differ-

ences in magnitude and simple conversions are taken

care of but also that any erroneous units being used in

an equation can be caught at compile time. However,

making a class hierarchy similar to the one illustrated

above could potentially involve hundreds of units and

thousands of conversions.

A more abstract approach is to bind the value

along with the unit in what is known as the Quantity

pattern (Fowler, 1997).

class Quantity {

private float value;

private Unit unit;

....

}

We can include arithmetic operations to the

Quantity class that ensures addition and subtraction

only succeed when their units are equivalent, or multi-

plication and subtraction generate a new unit that rep-

resents the derived value correctly. Moreover we can

include other useful behaviour such as printing and

parsing to this class.

Units can be deﬁned in the most generic form us-

ing an algebraic deﬁnition that includes two types,

base quantities and derived quantities. The base

quantities are the basic building blocks, and the de-

rived quantities are built from these. The base quanti-

ties and derived quantities together form a way of de-

scribing any part of the physical world (Sonin, 2001).

For example length (metre) is a base quantity, and

so is time (second). If these two base quantities

are combined they express velocity (metre/second or

metre × second

−1

) which is a derived quantity. The

International System of Units (SI) deﬁnes seven base

quantities (length, mass, time, electric current, ther-

modynamic temperature, amount of substance, and

luminous intensity) as well as a corresponding unit

for each quantity (The National Institute of Standards

and Technology, 2015).

These physical quantities are also organised in a

system of dimensions, each quantity representing a

physical dimension with a corresponding symbol (L

for length, M for mass, T for time etc.).

type base = L | M | T ...

Any derived quantity can be deﬁned by a combination

of one or several base quantities raised to a certain

power. These are called dimensional exponents (Bu-

reau International des Poids et Mesures, 2014).

type derived = Base of base

| Times of (derived * derived)

| Exp of (derived * int)

Dimensional exponents are not a type of unit or

quantity in themselves but rather another way to de-

scribe an already existing quantity in an abstract way.

Using the same example of velocity as before, it can

be expressed as:

Times (L, Exp (T,-1))

In concrete syntax this is instead expressed as L×T

−1

where L represents length and T

−1

represents the

length being divided by a certain time. Represent-

ing units in this manner is not always optimal as a

normal form exists which makes storage and, more

importantly, comparison a lot easier. Any system of

units can be derived from the base units as a prod-

uct of powers of those base units: base

×base

...base

, where the exponents e

,. .. ,e

are ratio-

nal numbers. Thus an SI unit can be represented as

a 7-tuple he

,. .. ,e

i where e

denotes the i-th base

unit; or in our case e

denotes length, e

mass, e

time

and so on. Thus 3 Newtons would be represented as

h1,1, −2,0, 0,0,0i, or 3 kg.m.sˆ-2. Dimensionless

units are represented by a tuple whose 7 components

are all 0. Interestingly any unit from any other system

can be expressed in terms of SI units. Conversions can

be undertaken using mostly multiplication factors, but

in some case offsets are required too.

This suggests implementing units through the fol-

lowing class outline:

class Unit {

private int [7] dimension

private float [7] conversionFactor

private int [7] offset

private String name

...

boolean isCompatibleWith (Unit u)

Quantity Checking through Unit of Measurement Libraries, Current Status and Future Directions

443

boolean equals (Unit u)

Unit multiplyUnits (Unit u)

Unit divideUnits (Unit u)

}

The dimension array contains the 7-tuple of base

unit exponentials. The attributes conversionFactor

and offset enable conversions from this unit system

to the SI units, while name is so that users can deﬁne

their own unit system.

The class Unit also deﬁnes operations to compare

and combine units. The method isCompatibleWith

checks whether two units are compatible for being

combined, such as miles and centimetres. While

equals returns true if the units are exactly the same,

which is used when adding or subtracting quan-

tities. When two quantities are multiplied then

multiplyUnits adds the two dimension arrays.

Correspondingly, divideUnits subtracts each of the

elements of the dimension array.

The idea behind a software design pattern is a gen-

eral, reusable solution to a commonly occurring prob-

lem. Due to the lack of an agreed interface to the

Quantity pattern, non-compatible domain speciﬁc in-

stantiations have proliferated as we shall demonstrate

in the next section.

3 ANALYSIS

A study of Unit of Measurement libraries (Bennich-

orkman and McKeever, 2018) has shown that there

is a lot of reinvention and little collaboration. By

analysing popular open-source repositories, the au-

thors discovered close to 300 active libraries for the

top twenty programming languages. A further reduc-

tion based on features, reputation and development

status brought this number down to 82 as shown in

Figure 1.

We have looked in more detail at a number of

these prominent libraries to elucidate how they op-

erate, their feature set and potential for interoperabil-

ity. All of the libraries we analysed implemented the

Quantity pattern, albeit in a number of different ways.

How each library in each speciﬁc language imple-

mented the pattern is detailed below.

3.1 Java

Two of the most prominent libraries written

in Java are CaliperSharp and the JSR 385

project (github.com/point85/CaliperSharp,

github.com/unitsofmeasurement/unit-api).

CaliperSharp implements the Quantity pattern

through the use of the class Quantity in which the

Amount is used to model the magnitude of the quan-

tity and UnitOfMeasure is used to specify the unit

for the quantity. In CaliperSharp, UnitOfMeasure is

deﬁned as an enumeration which contains all unit def-

initions that the library supports.

On the other hand JSR 385 implements the

Quantity pattern through the generic interface

Quantity<T> which each deﬁned (speciﬁc) quantity

then implements. For example:

Acceleration extends Quantity<Acceleration>

The quantity interface itself contains a deﬁnition

of a unit through the use of another interface, Unit.

This Unit interface also utilises the concept of physi-

cal dimensions to deﬁne the unit.

3.2 C++

The leading library for C++ is BoostUnits

(github.com/boostorg/units). It is in effect the

de facto standard and is actively developed, has very

good documentation, supports many units as well as

numerous different constants. BoostUnits is also part

of a big development team (Boost.org). However

Boost exploits the C++ template meta-programming

library so it is more than just a library as it supports a

staged computation model similar to MixGen (Allen

et al., 2004).

None of the other prominent programming lan-

guages have this ﬂexible compilation strategy so it

is an anomaly and even though it implements di-

mensional analysis in a general and extensible man-

ner, treating it as a generic compile-time meta-

programming problem, this style of software devel-

opment is radically different than a single stage com-

pilation.

The key advantage of this staged approach is

that with appropriate compiler optimisation, no run-

time execution cost is introduced, encouraging the

use of this library to provide dimension checking in

performance-critical code. Nonetheless, the core fea-

ture set is not too distinct from other libraries.

3.3 Python

The Astropy library (github.com/astropy/astropy)

has the single most commits out of all those presented

in (Bennich-Bj

orkman and McKeever, 2018), which

implies that it is also one of the most well-developed.

Like the previously presented libraries, Astropy has

the Quantity pattern at its root and, as it has so many

commits and contributors, it is feature rich. Much of

the functionality is built on top of its well engineered

core.

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

444

Figure 1: Leading unit libraries per language (Bennich-Bj

orkman and McKeever, 2018).

Another popular Python library is Pint.

(github.com/hgrecco/pint). It implements the

Quantity pattern explicitly as the central unit in the

library is the Quantity class with a magnitude and

a unit of measurement and this is how all units are

deﬁned. For example:

>>> import pint

>>> ureg = pint.UnitRegistry()

>>> 3 * ureg.meter + 4 * ureg.cm

<Quantity(3.04, ’meter’)>

3.4 C#

Looking at the number of commits, con-

tributors, comprehensiveness of the doc-

umentation as well as adoption, UnitsNet

(github.com/angularsen/UnitsNet) is one of

the best libraries overall, not only for C#.

Although UnitsNet also implements the same pat-

tern through the IQuantity interface, this is achieved

in a slightly different manner to other libraries shown

here. The type of the quantity and the value for the

seven base dimensions are the only attributes that are

deﬁned in the interface. The magnitude (or value) of

the quantity is added later as an operation for a spe-

ciﬁc unit that is calculated. The type for each quantity

is deﬁned as QuantityType which is an enumeration

containing all the quantities that the library supports.

This is similar to how it is handled in the CaliperShar p

Java library mentioned earlier.

In UnitsNet each speciﬁc unit is deﬁned as its own

class and utilises operator overloading to convert be-

tween units. The library also employs automatic code

generation to produce all the different conversions be-

tween different units.

Another capable library written in C# is Gu.Units

(github.com/GuOrg/Gu.Units). Similar to UnitsNet

it implements the Quantity pattern through the

IQuantity interface which deﬁnes a value (SiValue)

and a unit (SiUnit).

The unit of a quantity is deﬁned through the in-

terface IUnit which contains information about the

symbol for the unit, the base unit and ways to con-

vert the value of unit to its base value (kilometre to

metre for example) or from the base value. Another

similarity to UnitsNet is that Gu.Units also uses code

generation which leverages these interfaces to make

concrete quantities.

3.5 Javascript

A popular library for JavaScript is JS Quantities

(github.com/gentooboontoo/js-quantities). With

over 300 commits, it is one of libraries with

the most commits for the JavaScript language.

The library is also based upon another popu-

lar physical quantity library called Ruby Units

(github.com/olbrich/ruby-units) which is also

quite mature.

Similar to Pint, JS Quantities implements the

Quantity pattern through a general class called Qty,

which represents a generic quantity. A user can then

create whatever quantity they want through this class.

qty = Qty(’1m’);

qty = Qty(’1 N*m’);

qty = Qty(’1 m/s’);

qty = Qty(’1 mˆ2/sˆ2’);

qty = Qty(’1 mˆ2 kgˆ2 Jˆ2/sˆ2 A’);

qty = Qty(’1 attoparsec/microfortnight’);

In the example above, the use of dimensions and

dimensional exponents in JS Quantities is also show-

Quantity Checking through Unit of Measurement Libraries, Current Status and Future Directions

445

cased through the use of the Qty class. Similar to

other libraries, all the available quantities are deﬁned

in an enumeration.

4 EVALUATION AND FUTURE

WORK

In this section we postulate as to why we have arrived

at this state of affairs when the underlying comput-

ing science is well understood and Fowler (Fowler,

1997) provided an effective object model for units

of measurement some years ago. The Quantity pat-

tern has been shown to be applicable to mathematical

calculations, medical observations and ﬁnancial con-

versions. A more detailed and specialised version of

this pattern is provided by the Physical Quantity pat-

tern (Krisper et al., 2017) that looks in more depth

at the requirements of the physical and mathematical

sciences, presenting interfaces to enforce the use of

explicit quantity types. The key aspect is that the re-

search challenges are not technical in nature, more

work is required to create robust interfaces from the

Quantity pattern that engage the respective communi-

ties and gather traction. Even if these well engineered

interfaces existed, we suggest two other reasons that

hamper uptake.

The ﬁrst reason was put forward by

Damevski (Damevski, 2009) and is that scien-

tiﬁc programmers should not be burdened by units

at each statement in their programs, but that units

should be present in software component interfaces.

This makes sense when you consider that research

groups in, say, physics and chemistry departments

have evolved their own conventions, methodologies

and ontologies. Problems can arise when they try

to collaborate over energy conversions, for instance.

While the physicist works in terms of electron volts

per formula unit, the chemist thinks in terms of

kilojoules per mole. In such cases not only are the

units different but so are the magnitudes. In this

mode, each research group should be free to develop

their codes without unit annotations but when they

come to combining their codes with others, the

conversions need to be explicitly introduced.

The Logic of Collective Action (Olson, 2009) de-

velops a theory of political science and economics of

concentrated beneﬁts versus diffuse costs. Its central

argument is that concentrated minor interests will be

overrepresented and diffuse majority interests due to

a free-rider problem that is stronger when a group be-

comes larger. This is perhaps an explanation as to

why some of the libraries have continued to exist and

prosper when there are equally good ones for that par-

ticular language. Once developed and a user base has

accrued, due to the open-source nature of the endeav-

our, it becomes necessary to keep supporting the li-

brary as vital code has become dependent on its exis-

tence.

There are two central avenues of further work in

this area. We will interview scientiﬁc, medical and

ﬁnancial developers to elucidate their requirements.

Some users might be content with very lightweight

support, as envisaged by Damevski (Damevski,

2009). This would allow diverse teams to collaborate

even if their domain speciﬁc environments or choice

of unit systems were to some extent incompatible.

However other users might require a more robust en-

vironment in which all variables are given an explicit

unit or are dimensionless, and a checker will ensure

operational unit correctness. In-between we might al-

low static or dynamic unit conversions, the ability to

deﬁne new domain speciﬁc unit systems and a degree

of ﬂexibility that unit variables allow. Whether all of

these features need to be supported, and to what ex-

tent, is an open question that we hope to address in

the near future so that the Quantity pattern can be en-

riched with an effective API for modelling and imple-

menting units of measurement.

A second avenue that is urgently required is an un-

derstanding of the true cost of unit of measurement er-

rors. The big disasters grab the headlines but it is the

more mundane day to day outlay of defective code,

leading to incorrect results that could be more costly

yet is not reported. We mentioned earlier some infor-

mal ﬁgures describing the extent of the problem but

a more accurate understanding is needed. An open

source repository of defective unit error code would

allow researchers to explore techniques to detect, as-

sist and possibly recover from some form of unit er-

rors.

5 CONCLUSION

Our initial study of unit libraries (Bennich-Bj

orkman

and McKeever, 2018) highlighted an abundance of

similar contributions without a clear standard emerg-

ing. Unit libraries allow developers to faithfully rep-

resent quantities in their code and provide assurances

over correctness. These features are desirable from

both model and software engineering perspectives

as they reduce errors and encourage maintainability.

However they are not a requirement for creating exe-

cutable code.

In order to escape from this impasse we need

to know how people actually work with units. Are

unit libraries sufﬁcient? How can we ensure that

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

446

they are used unless mandated by the organisation.

Modern development workﬂows might favour sepa-

rate unit inferencing tools or unit checking to be un-

dertaken through testing instead. The needs of mod-

ern commercial systems, deployed on a vast number

of distinct devices, developed with a plethora of lan-

guages, evolving daily through continuous integration

is rather different to those of an academic research

group.

Numerous stakeholders, from developers upwards

to project managers in both small and large organisa-

tions need to be interviewed. Rather than focusing on

unit library or tool support, the purpose of our current

ongoing research is to delve into these broader top-

ics using questionnaires to understand the underlying

issues and causes.

REFERENCES

Allen, E., Chase, D., Luchangco, V., Maessen, J.-W., and

Steele, Jr., G. L. (2004). Object-oriented units of mea-

surement. In Proceedings of the 19th Annual ACM

SIGPLAN Conference on Object-oriented Program-

ming, Systems, Languages, and Applications, OOP-

SLA ’04, pages 384–403, New York, NY, USA. ACM.

Bennich-Bj

orkman, O. and McKeever, S. (2018). The next

700 unit of measurement checkers. In Proc. SLE,

pages 121–132. ACM.

Bureau International des Poids et Mesures (2014). SI

Brochure: The International System of Units

(SI), 8th Edition, Dimensions of Quantities.

Online https://www.bipm.org/en/publications/si-

brochure/chapter1.html. Last Accessed July 2nd,

2018.

Cooper, J. and McKeever, S. (2008). A model-driven

approach to automatic conversion of physical units.

Softw. Pract. Exper., 38(4):337–359.

Damevski, K. (2009). Expressing measurement units in

interfaces for scientiﬁc component software. In Pro-

ceedings of the 2009 Workshop on Component-Based

High Performance Computing, CBHPC ’09, pages

13:1–13:8, New York, NY, USA. ACM.

Dreiheller, A., Mohr, B., and Moerschbacher, M. (1986).

Programming pascal with physical units. SIGPLAN

Not., 21(12):114–123.

Fowler, M. (1997). Analysis Patterns: Reusable Objects

Models. Addison-Wesley Longman Publishing Co.,

Inc., Boston, MA, USA.

Garny, A., Nickerson, D., Cooper, J., dos Santos, R. W.,

Miller, A., McKeever, S., Nielsen, P., and Hunter, P.

(2008). Cellml and associated tools and techniques.

Philosophical Transactions of the Royal Society, A:

Mathematical, Physical and Engineering Sciences,

366.

Gehani, N. (1977). Units of measure as a data attribute.

Computer Languages, 2(3):93 – 111.

Hilﬁnger, P. N. (1988). An ada package for dimen-

sional analysis. ACM Trans. Program. Lang. Syst.,

10(2):189–203.

Jiang, L. and Su, Z. (2006). Osprey: A practical type sys-

tem for validating dimensional unit correctness of c

programs. In Proceedings of the 28th International

Conference on Software Engineering, ICSE ’06, pages

262–271, New York, NY, USA. ACM.

Joint Committee for Guides in Metrology (JCGM) (2012).

International Vocabulary of Metrology, Basic and

General Concepts and Associated Terms (VIM). On-

line https://www.bipm.org/en/about-us/. Last Ac-

cessed November 20th, 2018.

Krisper, M., Iber, J., Rauter, T., and Kreiner, C. (2017).

Physical quantity: Towards a pattern language for

quantities and units in physical calculations. In Pro-

ceedings of the 22Nd European Conference on Pattern

Languages of Programs, EuroPLoP ’17, pages 9:1–

9:20, New York, NY, USA. ACM.

Mayerhofer, T., Wimmer, M., and Vallecillo, A. (2016).

Adding uncertainty and units to quantity types in

software models. In Proceedings of the 2016 ACM

SIGPLAN International Conference on Software Lan-

guage Engineering, SLE 2016, pages 118–131, New

York, NY, USA. ACM.

Modelica (2018). Modelica and the Modelica Association.

Online https://www.modelica.org. Last Accessed on

November 12th, 2018.

Olson, M. (2009). The Logic of Collective Action: Pub-

lic Goods and the Theory of Groups, Second printing

with new preface and appendix, volume 124. Harvard

University Press.

Ore, J.-P., Detweiler, C., and Elbaum, S. (2017).

Lightweight detection of physical unit inconsisten-

cies without program annotations. In Proceedings

of the 26th ACM SIGSOFT International Symposium

on Software Testing and Analysis, ISSTA 2017, pages

341–351, New York, NY, USA. ACM.

Ribeiro, F. G. C., Rettberg, A., Pereira, C. E., and Soares,

M. S. (2016). An analysis of the value speciﬁcation

language applied to the requirements engineering pro-

cess of cyber-physical systems. IFAC-PapersOnLine,

49(30):42 – 47. 4th IFAC Symposium on Telematics

Applications TA 2016.

Sonin, A. A. (2001). The physical basis of dimensional

analysis. Technical report, Massachusetts Institute of

Technology.

Stephenson, A., LaPiana, L., Mulville, D., Peter Rut-

ledge, F. B., Folta, D., Dukeman, G., Sackheim,

R., and Norvig, P. (1999). Mars Climate Orbiter

Mishap Investigation Board Phase 1 Report. On-

line https://llis.nasa.gov. Last Accessed on November

20th, 2018.

The National Institute of Standards and Technology (2015).

International System of Units (SI): Base and Derived.

Online https://physics.nist.gov/cuu/Units/units.html.

Last Accessed July 2nd, 2018.

TIOBE (2018). Tiobe (The Importance of Being Earnest)

company index for November, 2018. Online

https://www.tiobe.com/tiobe-index/. Last Accessed

on November 20th, 2018.

Wand, M. and O’Keefe, P. (1991). Automatic dimensional

inference. In Computational Logic - Essays in Honor

of Alan Robinson, pages 479–483.

Quantity Checking through Unit of Measurement Libraries, Current Status and Future Directions

447