-14-

An Example of a
Unit of Measure Code Table
01 piece-each 31 pint
02 pair (2 pieces) 52 quart
03 set 33s gallon
04 = roll 54 half gallon
OS = sheet 55 imperial pint
06 C (100 pieces) 56 imperial quart
07 = gross (144 pieces) 57 imperial gallon
08 ream (500 sheets) $8 imperial half gallon
oo obale 59 fluid ounce
10 coil 60 imperial fluid ounce
11 inch 61 1000 pieces
12 foot 62 0.1 piece
13° syard 63 0.01 piecs
14 sq yard 66 cubic inch
15 bd foot 68 dram - apothecaries
16 sq inch 69 ounce - apothecaries
17 ‘sq foot 70 pound - apothecaries
18 cu foot 71 box - package
19 100 feet 72° carton
20 fathom 73 tube
21°) meter (m) 74 barrel
22 ~~ centimeter (cm) 7S drum
230 sqmeter(m*) 76 tank
25 sq centimeter (cm*) 77 case
26 = millimeter (mm) 78 carboy
28 sq millimeter (mm’) 79° keg
80 cylinder
31° ounce - avoirdupois 81 dozen (12 pieces)
32 pound - avoirdupois 82 pad
33 100 weight 83 spool
34 ton - short 84 ball
35 metric ton 85 jar
36 ounce - troy 86 bottle
37 pound - troy 87 card
38 dram - avoirdupois 88 = label
39 pennyweight 89 lot
40 grain 90 can
41 gram (g) 91 tablet
42 kilogram (kg) 92 cone

43 cubic decimeter (liter) (L)

44 cubic centimeter (milliliter) (mL)
45 carat

47 cubic meter (m’)

48 9 cubic millimeter (mm’)

49 ~~ milligram (mg)

NOTE: Unit of Measures are grouped in Categories. Missing aumbers will allow for
additional terms to be inserted.

anMc © 1010 vermont avenue, n.w., suite 320, washington, dc 20005-4960 [202] 628-5757


point in time there may be only “inch” equipment, or there may be both metric and inch
equipment or just metric equipment. For the first case, the inch dimension would be used.
In the second case, depending on workload across the machines, either metric or inch might
be necessary. Finally where metric-only machines are available, only the metric dimensions
would be needed. Wherever possible, the use of dual capability should be avoided, cr else
be maintained for as short a time as possible. Several factors required for dual capability
affect the use and cost of maintaining the capability. These factors are enumerated in the
following subsections.
4.2.2.1 Unit of Measure Identifiers
The need to carry both SI and inch-pound units in the same program requires that there be a
means to differentiate between the two. This may be handled by means of an unit of
measure identifier. Within a specific program using only a few units of measure, this
identifier may be a single numeral or alphabetic character. In situations where there are
many programs using many different units of measure, the unit of measure may be converted
to and processed as a code as shown in Appendix B. Use of an identifier means that an
additional one or two spaces are required for both input and output - spaces which may not
be readily or easily available. Also, the computer has to store and transact this additional
information, thereby increasing storage cost and transaction time.
4.2.2.2 Additional Fields, Storage, and Transactions
As with the identifier mentioned previously, the need to carry both SI aad inch-pound units
approximately doubles the original space required in fields, storage, and time for the
necessary transactions. Special planning is required to ensure that:

1. The input and output documents are revised to accommodate the extra space required

for both sets of data.

2. The computer will have sufficient memory storage.
3. Allowance is made for the extra time that may be required to run the program.
4.2.2.3 Conversion of Duai Capability to Metrie Only

The design of any dual capability program should include, at the outset, ability to delete the
inch-pound measurements from the program automatically. Since the dual capability is
needed only for am interim period during which equipment is being converted to metric
capability, the automatic removal feamre is desirable upon completion of that period.
Including this removal feamre in the original design will be easier and less costly than at a
later point in time. If added later, the details of the Program must te completely reviewed
by the Programmer to determine if and how the feature can be designed into the program.
This can delay the deletion of the information beyond the time when it is needed, with the
attendant costs of continued dual maintenance.
Tn summary, dual measurement capability may require some or all of the following:

1. New programs (when existing programs cannot be changed).

2. Program changes (to existing programs).

3. Unit of measure codes, symbois, or forms.

4. Extra fields and/or identifiers for information on input/output.
Additional computer storage for the paraile! information.
Additional transactions (time).
Changes to forms (input and output).

“

so

ANMC © 1010 vermont avenue, n.w., suite 320, washington, dc.20005-4960 [202] 628-5757


-18-

References
1. 8031/0 - General principles concerning quantities, units
and symbols.
2. ISO 311 - Quantities and units of space and time
3. ISO 31/2 - Quantities and units of periodic and related
phenomena
4. 180 313 - Quantities and units of mechanics
5. [SO 31/4 - Quantities and units of heat
6. ISO 31/5 - Quantities and units of electricity and magnetism
7. TSO 316 - Quantities and units of light and related
electromagnetic radiations
8. ISO31/7 + Quantities and units of acoustics
9. ISO 318 - Quantities and units of physical chemistry and
molecular physics
10. ISO 3/9 + Quantities and units of atomic and auclear
physics
ll. So 31/10 + Quantities and units of nuclear reactions and
ionizing radiations
12. GO3V11 - Mathematical signs and symbols for use in the
physical sciences and technology
13. ISO 31/12 - Dimensionless parameters
14. ISO 31/13 - Quantities and units of solid-state physics
15. Iso 1000 - Sf units and recommendations for the use of their

multiples and of certain other units
16. ANSI Z210.1 (IEEE STD-268) - Standard for metric practice

17. AST E-3380 + Standard for merric practice

18. ISO 2955 - ‘Information processing-Representation of SI and
other units for use in systems with limited
character sets

19. AFWAL-TR-80-4110 - Merrication of MIL-HDBK-SC

20. ISO 3461 - Graphic Symbols, General Principles of
Presentation

21. ANSI Y32.2 - Graphic Symbols for Electrical and Electronics
Diagrams

22. CAN-Z234.1 - Canadian Metric Practice Guide :

23. ANMC Metric Editorial Guides - Guide to standards of format and style for metric
unit display

24, FED STD-376 + Preferred Metric Units for general use by the
Federal Government

anmMe e 1010 vermont avenue, n.w., suite 320, washington, dc 20005-4960 [202] 628-5757




-15-

Appendix C

List of Acronyms and Definitions


-17-

Appendix D
Bibliography


-12-

This table, a portion of the information in ISO 2955, shows some of the alternate symbol
arrangements which may be used when the proper symbols are not available.

ISO 2955 is available from the American National Standards Institute.

Inter- Representation
national
Symbol Form I Form I
(common | (double | (single | (single
Name of use case) case case
Unit symbol) lower) | upper)
5.1 Base SI Units
metre mn m m M
kilogram | kg kg kg KG
second s 3 s
ampers A A a A
kelvin K 4 k K
mole mol mol mol MOL
candela od cd cd cD
5.2 Supplementary SI Units
radian rad rad rad RAD
steradian | sr st st SR.
5.3 Derived SI Units with special names
hertz Hz Hz hz. HZ
| newton N N a N
pascal Pa Pa pa PA
joule I I j I
watt Ww Ww w Ww
coulomb [| C Cc c Cc
volt Vv Vv v Vv
farad F F f F
ohm Qa ohm chm OHM
siemens Ss s sie SIE
weber Wo Wo wo WB
tesla T T t T
henry H H bh H
lumen im Im im iM
lux kx ix ix LX
bequerel | Bq Bq bq BQ
sievert Sv Sv sv SV

anme e 1010 vermont avenue, n.w,, suite 320, washington, dc 20005-4960 [202] 628-5757


elements which are measurement-sensitive; one with intercepts denoting data classes vs.
program affected; and one with intercepts of data classes vs. business process/function which
requires the data. The concept here is that, in the event all portions of the conversion to
metric cannot be implemented at one time, it will be possible to establish priorities for the
phased support of different functional units or organizations of the business. If constraints
dictate a phased implementation approach for the transition to metric, it is suggested that a
data flow model for measurement-sensitive data be developed. The intent is to arrive at an
implementation scheme that provides a road-map to a subsystem by subsystem conversion.
(by subsystem we mean a logical grouping of programs which support a business activity.) In
any system where data sharing is a requirement between subsystems the set of matrices can
be used to identify the relative independence of data classes and the processes or activities
they support.

3.3 Implementation Design Planning

In any type of phased approach, in the absence of any other business consideration, one
would take a bottom-up approach to implementation by first choosing conversion of data
classes (and subsystems that use them) which have low interaction with other data classes.
Although the forgoing is aimed at the analysis of large systems, the technique is equally
applicable for more narrowly defined projects (such as the conversion of a single system).
Secondary issues for the analysis that ought to be considered include:

1. The examination of program calculation logic to assess the need for change (i.e.,
calculation accuracy).
2. A scan of programs and data tables/files for built-in constants/data values which might
require change.
3. Review of input/output format and symbol presentation.
The rationale for including analysis cf the latter items is addressed more fully in the
following section covering detailed implementation guidelines.
In summary, the impact on the DP organization for any transition to metric effort can be
assessed and quantified after two major investigative efforts: 1. a requirements definition
study; 2. an analysis of current systems. These two efforts provide the information necessary
to define the project development plan which presents the impact statement in terms of
schedules, resources, and deliverables.

4. Implementation Guidelines/Ismes

This section is designed for the software developer or manager and for the project staff to
use in determining how to implement a decision to handle metric information or metric and
inch-pound information in a software system.

The guidelines and issues are covered in general terms in order that they be applied to as
many different projects as possible, from scientific to administrative, from small specialized
Programs to be rum on microcomputers to large general purpose programs to te mun on
mainframe computers. Mlustrations and examples used are to clarify the guidelines cited and
are not intended as models. Most real life simations will not be as simple nor as
straightforward as these examples. It is the intent of the ANMC DP/OE Sector Committee to
redefine and expand these guidelines as metric applications increase and lessons are learned.

ANMC » 1010 vermont avenue, n.w., suite 320, washington, de 20008-4960 [202] 628-5757


Appendix A
Appendix B
Appendix C
Appendix D

LIST OF APPENDICES

Alternative Symbols for Use in Systems
with Limited Character Sets

An Example of a Unit of Measure Code Table
List of Acronyms and Definitions

List of References


4.2.2.3 Conversion of Dual Capability to Metric Only. . 2 2...) 8
4.2.3 Computational Operations 2 2... ee ee eee OD
4.2.4 Output Presentation Formats. 2. 6. 1 ee ee te ee ee

4.2.5 Historical Data 2 ww eee ee

@ANMC © 1010 vermont avenue, nw., suite 320, washington, dc 20005-4960 [202] 628-5757


Appendix B
An Example of a

Unit of Measure Code Taole


commanding, role in the transition. The rationale for selecting DP is that the support of
essential automation services to all of the interrelated activities of the various functional
organizations is foeused in that organization. In the pivotal position, DP is in perhaps the
best position to coordinate and monitor the change with all affected functions.

3. Assessing the DP Impact

Tt is assumed that either as part of the initial decision process or as a result of it, the DP
organization will be called upon to determine the impact of a change to metric on the
enterprise’s information systems and DP’s support to the various user organizations.

The quantifications of the impact will normally involve two broad investigative steps and a
design and planning effort:

1. Definition of new requirements.

2. Analysis of current systems.

3. Implementation design planning.

These steps are preparatory to the establishing of scope, schedule, and rescurce demands for
the conversion effort. Later sections of these guidelines are devoted to an examination of the
requirements, analysis, and implementation planning issues. Not explicitly addressed, but
certainly to be noted, are such items as the operational impact of performance changes (i.¢.
Tun-time extensions) and the facilities planning impact of possible changes to peripheral
hardware or operating system software. The latter as a result of new data storage or new
output device requirements.

As im any project there are tradeoffs to be considered in terms of scope, delivery dates,
resources, and the quality of the deliverable. It is the responsibility of DP management to
balance the constrained elements of the project to arrive at a commitment to deliver a given
capability, at a given cost in terms of time and resources. An up-front statement of objective
and a consensus on the constraints of the project greatly simplifies the process.

3.1 Definition of New Requirements
The major objectives of the requirements definition step are to:
1. Define the scope of change desired.

2. Identify new standards required, i.e., tolerances, data field length, computational
accuracy, Measurement code identifiers.

3. Identify educational program requirements for perscnnel.
4. Identify performance (service/response time) requirements.
5. Identify known priorities and critical delivery dates.
6. Determine the need to change historical data.
3.2 Analysis of Current Systems
The main purpose of this step, the analysis of current systems, is to determine:
1. Usage of measurement-sensitive data across program elements (modules).

2. Input/output capabilities requiring SI units specification. The analysis is then passed to
the implementation design and pianning step.

This information should be readily available from the data administration function (i.¢., from

data dictionary, if maintained). Ctherwise a review of code and data may be necessary. In

addition to code review, a useful analysis tooi is a set of matrices - one with intercepts

denoting data classes (a grouping of data elements into logically rejated categories) vs. data


PB86-240215

Guidelines for Metric
Transition of Software

American National Metric Council, Washington, DC

Oct 85

U.S. DEPARTMENT OF COMMERCE
National Technical Information Service


measurement schemes. Decisions must be made up front on mixed units, dual units (inch-
pound and equivalent metric units side by side), use of one system exclusively, or variations
as the user dictates from one application to the next. Each of these alternatives has its own
advantages and disadvantages. Mixing units generally is not beneficial since it precludes user
comparison of sequential values and increases the probability of confusion as users try to
mentally convert units to those with which they are familiar. Dual units permit direct
comparison but use valuable output space. (Ses Paragraph 4.2.2 for more detail.) If
possible, using one system is most effective and efficient if the users can agree that one set of
units is preferred. This also simplifies internal computations. Dictation of the output units
by the user customizes the output to each user’s m but at the expense of performance, as
added complexity is needed to convert all or most of the data prior to output. (See Section
4.2.4, Output Presentation Formars.)

4.1.3.2 Machine Software Interface Factors

Many times a system’s output is required as input to other software programs, machines, or
systems whose method and type of input is fixed, such as the following:

1. Numerical control machine tools.
2. Systems and programs for which source code is unavailable.
3. Systems that are already in doubie or extended precision.

For these situations, the developer/manager has no option but to use the current units of
input as defined by the older, existing programs, machines, or systems.

If, however, the program, machine, or system is being developed in conjunction with
metrication activities, then there can be more tailoring of its input and output formats,
including the units in which cach will converse with the other.

4.1.4 Accuracy/Precision

When involved in conversion from one system to another, the developer must consider
whether or not to retain the same or similar level of accuracy and precision in the conversion
results as in the original numbers. Common sense, based on knowledge and experience,
should be a determinant in choosing practical, meaningful magnitudes for the specific case
involved. For example, the speed limit on the aation’s interstate highways is $5 mph. A
Precise equivalent of 88.5115 kilometers per hour results from direct mathematical
conversion. A conversion to 90 kilometers per hour might be a more meaningful resulting
speed limit, maintaining the original intent of the value, but not the accuracy of the
translation process. In the case of converting from the inch-pound system to the metric
system, retaining the original precision often results in more digits being recorded or stored.
(1.0 inch = 25.4 millimeters; 1.0 mile = 1.609 kilometers.) The developer must be attentive
to data storage and input/output formats to allow for this. In addition, storage of the data
must be large enough to handle any increase in the number of digits necessary to maintain
computational accuracy. Accuracy can be achieved by paying close attention to accurate
conversion factors and conventional rounding guidelines. Federal Standard-376A is the
guideline to follow for proper use of units and conversion factors. ANSUIEEE STD-268 and
ASTM £E-380 also present guidelines for metric practice including rounding mules. In some
instances, it may be found that some existing programs already contain metric measurement
information either alone or in a dual mode. These programs may have been designed to an
older metric system which does not conform to ail SI requirements of style and symtology.
Finding and correcting these symbols, the style, and the formar to SI requirements will
require programming changes and will affect field sizes and space requirements. As a mule,
back and forth conversions, however, should be discouraged to reduce error compounding.
In some cases, where preprinted input and/or output forms are used, the preprinting may also
have to be changed, Proper usage of SI is especially important when the output is to be used

AMMC «@ 1010 vermont avenue, n.w., suite 320, washington, de 20005-4960 [202] 628-5757


4.1 Design Issues
The design issues include:
1. Conversion Decision
2. Development Time
3. Interface Requirements
4. Accuracy/precision
5. Performance
4.1.1 Conversion Decision

Implementing a decision to go wholly or partially metric will be more or less efficient than an
inch-pound system depending on the complexity of the requirement to be metric.

At one extreme is a program required to periodically provide metric information as its output
with the usual output in inch-pound units. A more difficult requirement to implement is one
where data storage and/or computation and/or /O must accommedate metric. An even more
difficult decision to implement is one where the inpuvourput will be beth inch-pound and
metric to varying degrees. An example is the recording in a state repository of newborn data
from various hospitals - some recording mass in kilograms, some recording lengths in
centimeters and some recording everything in inch-pound units.

4.L2 Development Time

Every project is constrained by development time; the trick is to make the mest efficient use
of the limited time available. Development tims is not likely to be affected greatly by a
decision to. handle only inch-pound or only metric data. It will be more affected by a
decision to handle a mixture of inch-pound and metric data. Decisions.on how to effect
conversion between measurement systems - the location in the program where the
conversions take place, which system the data bases shouid be designed in, and evaluating
future changes that will impact the above, are just some of the additional questions that must
be answered along with all the other ordinary technical decisions made before deveicpment
time. For instance, information gathered from many sources, some metric and some inch-
pound, may be fed into a program in the units in which it is gathered. The program then
converts ail inch-pound data to metric units before analyzing the data. The output may then
be converted back to inch-pound units for display and stored in metric units for future
analysis. Another useful rule is to convert historical information to another system of units
only if there is some overriding benefit, such as an increase in performance with no loss of
accuracy. (See Paragraph 4.2.5 for more detail.)

4.1.3 Interface Requirements

Both human and machine software interface requirements need to be considered in the design
phase.

4.1.3.1 Homan Factors

One of the more difficult areas for program developers and managers is the interface with
humans. This is compounded when cperating in two measurement systems. Confusion,
inaccurate computations, and meaningless output will result from inputting inch-pound and
metric umits without adequate training and safeguards. Measurement units of certain
characteristics such as pressure (inches of mercury, bars) and velocity (ft/sec, miles/hour) are
ambiguous even in one system of measurement. Sometimes it will te necessary to specify, to
the processor’s system, the units used. This will affect performancs, system design and
storage requirements. Outputs will also be affected. The units of measurement ought now be
(either explicitly or by differing forms) shown to reduce confusion between dual


1. Introduction

This document has been prepared by the American National Metric Council (ANMC) Dara
Processing and Office Equipment (DPIOE) Sector Commitee to assist information systems
managers in understanding the effect of metric usage in software programs containing
measurement-sensitive data fields. Guidelines are provided for the implementation of change.

Metric changeover can have a significant impact on software. For those caught unprepared,
it can be a costly and time-consuming process to convert programs or to provide for dual
usage (metric and inch-pound units in the same program). The costs are minimized,
however, when managers are prepared to meet the challenges of incorporating metric units.
With their expertise and knowledge of number systems, data processing professionals will
find the International System of Units (ST) rational, consistent, and straightforward. Therein
lies the opportunity for achieving substantial long-term tenefits.

It is the responsibility of corporate management to decide how and when the transition
should be undertaken. The ANMC helps ail sectors of the economy to plan and coordinate
sector conversion plans. The climate for planning and implementing metric changeover
strategies has been steadily improving. In fact, most of the companies in the Formune 1000
believe predominant metric usage is inevitable.
Tt is assumed that the decision for transition to the International System of Units (SI) has
already been made by top management. Sincs computer services are an important element of
any metric transition, this guide is intended to assist data processing managers, professionals,
and users in:

® assessing the impacts of use of the SI metric measurement units and standards on

computer software systems, and

making the decisions necessary for efficieat software conversion.

Hereafter in this document, any reference to metric measurement implies the use of Ls
Systeme Internationale d’ Unité/SI (or, as it known in the U.S., the International System of
Units).

Data Processing (DP) personnel, that is, systems programmers, application designers and
programmers, and management personnel, will find that the SI system of units is a
straightforward, rational system that will fit weil with their skills and needs. It is in (1) the
application of the SI system with proper use of its symbols and in (2) the general interaction
of the measurement system, standards, and the computer system where they will find the
greatest impact. Those planning issues and implementation design issues which are of major
importancs in assessing this impact are presented in the following guide.

This DP/Software guide will nor concern itself with the detailed design of measurement
conversion algorithms such as the conversion of metric to inch or inch to metric dimensions.
Such algorithms are straightforward and many programs implementing them have already
been writ. Reference documents for designing such algorithms are cited in Appendix D.

2. Plamming the Change to Metric

A decision to adopt the SI system will ordinarily involve a commitment for the entire
organization. As such, the requirement to implement the change to metric in information
procsssing will normaily not come about as a decision of data processing management. The
timing and methodology for implementation are often determined jointly by functional line
organizations and the DP service organization. The task of directing and controlling the
introduction of change should normally be a corporate/company metric coordination function.
Depending on the size and complexity of the undertaking and the aumber of internal
organizations affected, the coordinator may take the form of a special task force or a key
individual. In fact, the DP function should play a central coordinating, if aot a

@NIMC @ 1010 vermont avenue, n.w., suite 320, washington, dc 20005-4960 [202] 628-5757


-16-

ANMC American National Metric Council

CPU Central Processing Unit

CRT Cathode Ray Tube

DP Data Processing - the execution of a systematic
sequence of operations performed upon data.

Dual Dimensioning The Practice of showing both Si and inch-pound
values.

1. “Metric Prime” is SI first with inch-pound values
following in parentheses.

2. “Inch-pound Prime” is inch-pound first with SI
values following in parentheses.

Function In the context of this pian, a function is one of a
group of relnted actions contributing to a larger
action.

Hardware The physical requipment required to verform the data

processing operation.

Hybrid Metric hybrid refers to the practice of designing and
Manufacturing metric equipment and using inch-pound
standard’ parts in places where it is not economical to

change.

vo Inpuy/Output

IP InctyPound; formally referred to as customary or
conventional.

Metrication/metric conversion The act of changeover from the use of t= inch-pound
system of measurements to the SI version of the
Metric system of measurements.

Software The entire set of programs, procedures, and related
decumentation associated with a data processing
system.

@AMC @ 1010 vermont avenue, nw., suite 320, washington, dc 2CO05-4960 [202] 628-5757


BIBLIOGRAPHIC INFORMATION

PB86-240215
Guidelines for Metric Transitionof Software.
Oct 85

PERFORMER: American National Metric Council, Washington,
pc.

The document has been prepared by the American National
Metric Council (ANMC) Data Processing and Office Equipment
(DP/OE) Sector Committee to assist information systems
Managers in understanding the effect of metric usage in
software programs containing measurement-sensitive data
fields. Guidelines are provided for the implementation of
change. Contents: Alternative symbols for use in systems
with limited character sets; An example of a unit of measure
code table; List of acronyms and definitions; List of
references,

KEYWORDS: *Metric system, *Units of measurement,
*Conversion, *Data processing, *Managers,
*Foreign technology, *Computer software, *Data
base administrators, *Management information
systems.

Available from the National Technical Information Service,
SPRINGFIELD, VA. 22161

PRICE CODE: PC A02/MF AO1


8. Use of alternate symbois permitted (See Appendix D, Reference 18).
9. Programming for converting to SI mode cnly.

Establishing, maintaining and handling dual measurement information can create a
considerable cost impact. Advance planning can reduce that impact. The best approach is to
plan the changeover directly to metric measurements alone and completely avoid the need for
a dual system. Since this is not always feasible, the next best approach is to design all new
programs and forms to handle both systems, even if the dual nesd is still in the fumre.
When planned for early, this can be done at practically no extra cost. There will still be
seme impact due to having to handle the extra information in space and transactions, and on
new forms where dual measurements are unavoidable.

4.2.3 Computationai Cperations

Scientific and engineering (S&E) programs are mainly mathematical computation programs.
Operational programs, on the other hand, are data manipulators although conversions may be
calculated during this manipulation: that is, a measurement in one system is simply converted
to a measurement in the other system. The S&E programs take measurements or other data
in one measurement system and apply them to formulas with constants and/or tables of data
and compute a desired result in the same measurement system. Changing these programs to
use the metric system of measurement will not change the theory, but it requires that the
constants and/or tabies of data used in and with the formulas and programs te changed to
accommodate the metric system. Preprocessing or post-processing routines might possibly be
written to handle some of the conversions from one system to the other. Many formulas and
Programs are very complicated and only extensive modification and rewriting will serve the
purpose of operating with the new system. Formulas use measurements, constants, and
lookup data. If a particular constant is meusurement-based, a new SI constant may need to
be-established. The investigator will find that considerable research may be necessary to
determine ths origin of some constants. Tables of data, such as shear or tensile strengths,
which are based upon the preseat inch-pound systema, must also be converted to SI or else
new SI tables must be created. Introducing ‘uilt-in conversion tables of inch-round to SI
values, sizes, constants, and so forth, however, will not result in conversions to exact
equivalent metric values. Where accuracy is required, tables of preferred SI values should be
used by programs.

4.2.4 Output Presentation Formats

The SI units are defined in ISO 1600 and further developed in ISO 31/0 through ISO 31/13.
The style or format is also partially defined in ISO 1000 with detail provided in ISO 31/0.
(See Appendix D, Reference 1 through 15.)

The SI units can be handled by any computer, however, the international symbols depicting
the units and prefixes are required to te shown in upper and lower case roman upright type.
Furthermore, ons unit (ohm, 2 ) and one prefix (micro, » ) are represented by Greek
characters. For details, refer to the afcrementioned ISO standards and the ANMC Metric
4.2.3 Historical Data

Historical data that needs to be converted may be handled in various ways. The data should
be converted to SI in advance of when it is required. Because the conversion is coming about
due to the organization’s decision to go metric, the historical data should be converted to SI
for comparison rather than converting new metric data to inch-pound units. If the ourput is
on preprinted forms, the forms will have to be changed. On many occasions, it will be
necessary to suppress the inch-pound historical data in the new program and process che
current SI data, calling upon the historical data only when comparisons ars required.


-l-

Appendix A

Alternative Symbols for use in Systems with Limited Character Sers


CONTENTS

. Introduction 6. 6 6 we ee ee ee ee ee

. Planning the Change to Metric . . 2... 1 we
. Assessing the DPImpact . . 2... 2... eee ee
3.1 Definition of New Requirements . . . we
3.2 Analysis of Current Systems . 2. . .
3.3 Implementation Design Planning. . 2... wwe
. Implementation Guidelines/Issues . 2 2 1.
4.1 Design Issues 2. 2 2 2 1 we ee ee

4.1.1 Conversion Decision 2. 2 1... 1

4.1.2 Development Time . 6 2 1 6 ee ee ee

4.1.3 Interface Requirements 2 6 2 ww ww
4.1.3.1 Human Factors . 1... 1 we
4.1.3.2 Machine Software Interface Factors

4.1.4 Accuracy/Precision .

4.1.5 Performance ... 1... 2.2.20.

4.2 Design Techniques 2... 2... 1. eee

4.2.1 Preprocessors and Post-Processors . 2 2 1 we

4.2.2 DualUnis 2... 1 ee eee
4.2.2.1 Unit of Measure Identifiers . 2...

4.2.2.2 Additional Fields, Storage, and Transactions

eiew

ua

uw


PB86-240215

GUIDELINES
FOR
METRIC
TRANSITION
OF
SOFTWARE

DATA PROCESSING/OFFICE EQUIPMENT
SECTOR COMMITTEE 2.10

OCTOBER, 1985

= american
nationai
metric

= council

REPRODUCED BY
NATIONAL TECHNICAL
INFORMATION SERVICE

US. DEPARTMENT OF COMMERCE
SPRINGFIELD, VA.” 22161

anmme e 1010 vermont avenue, n.w., suite 320, washington, dc 20005-4960 [202] 628-5757


in countries where SI is a legal requirement. Standards which are related to the program may
also require changing. Examples of incorrect symbology for the term microfarad are: MF Mf
MED Uf UFD Mfd. The correct SI symbol for microfarad is .F. For systems with limited
character sets, ISO 2955 (See Appendix D, Reference 18) permits: uf or uF. Investigations
have found that handheld calculators and some conversion programs have different
conversion factors programmed into them. It is important to compare the calculated results
with known accurate conversions so that the desired accuracy is ensured.

4.1.5 Performance

Most decisions on how to implement both metric and inch-pound information will be driven
by performance considerations. The requirement statement will help make technical
decisions such as pre-processing conversion vs. post-processing conversion. The developer
must trade off storage capability, processing time, and [I/O time. Many times during the
period of active industry and government transition to the metric system, the developer must
make estimates as to future uses of the system. In the example of the newborn data used
above, how the data is processed, stored, retrieved and presented to ths user will depend on
how often inch-pound data is inputted, and required for output and computation vs. how
often metric data is inputted, outputted, or used for computation, over the life of the new
system under development. For a long-lived program, the transition from inch-pound to
metric could be well along toward predominate use of metric units. The developer must take
care not to prematurely render the system obsolete because provisions for efficient use of
metric units were not made.

4.2 Design Techniques
Programming techniques for the following areas need to be considered in the design phase:
1. Preprocessors and Post-Processors
2. Dual Units
3. Computational Operations
4, Output Presentation Formats
5. Historical Data
4.2.1 Preprocessors and Post-Processors

These are usually fairly simple programs used to perform operations om data before
(preprocessors) or after (post-processors) it is acted on by the existing primary program.
There are preprocessor routines which will convert SI information into non-SI information so
that it may be processed by the primary program which was originally designed for non-SI
dimensions. Post-processors take non-SI information and process it back into SI units for
output. The use of preprocessors and post-processors is not very often a successful solution
to all programs. When investigating exactly how the data is handled in the primary program,
extreme care must be taken to determine whether or not it is possible to use this approach.
Furthermore, when it is used, very careful attention must be given to the mies which are
applied for conversion and rounding of the data to achieve the required accuracy (See
Paragraph 4.1.4). An added complication arises when converting the information through
both a preprocessor and again through a post-processor. The double conversion compounds
the inaccuracies due to rounding and may affect the accuracy of the data which is required.
4.2.2 Dual Units

During the early phase of the changeover, many new and existing programs will need to have
the capability of handling both SI and inch-pound information. For example, during the
period of time when manufacturing equipment is being converted to metric or being replaced
by metric equipment, both sets of measurements will be needed. This is because at any given


-10-

5. Summary

As intensive an investigation as kas been espoused will undoubtedly uncover many situations
where an organization can realize significant savings. This could come about through the
elimination of programs which are no longer needed, by combining two cr more programs to
streamline operations and reduce computer time and storage, and through the elimination of
redundancy in programs, tables, files and data bases. In other words, it becomes an excsilent
opportunity to clean house. For those who are concerned ‘with the costs of metrication, close
monitoring of the advantages gained can provide a return on investment which will in some
cases easily offset the costs.

The foregoing discussion on the impact of metrication of software has revealed many aspects
which must be considered to implement a successful conversion to metric. To summarize,
the following aspects must be considered when changing computer systems software to
metric.

The SI System and rules of usage in new/existing programs.
© Character availability in input/output devices.

¢ Si symbol character alternatives.

© Need to design new programs.

« Need to modify or obsolete existing programs.
Preprocessing or post-processing routines.

« Dual measurement transaction capability.

© System running time (input, CPU, and output).

Field and line space requirements.

Forms changes.

© Program interface requirements.

« Computational operations factors.

© Conversion of existing (or development of new) tables of data.
« Historical data.
-@ Improving operations.

A myriad of detail is covered by the above list, attention to which is crucial for any successful
implementation of metric. Moreover, it is deemed important that some level of planning
effort take place now, so that proposed project can te designed with metric in mind...even
though full conversion may still be some time distant.

anme e 1010 vermont avenue, n.w., suite 320, washington, de 20005-4960 [202] 628-5757