NTEP Committee 2014 Final Report 

Appendix E – 2013 NTEP Software Sector Summary 

NTEP - E1 

Appendix E 

National Type Evaluation Technical Committee (NTETC) 

Software Sector Meeting Summary 

March 19-20, 2013 

Columbus, Ohio 

INTRODUCTION 

The charge of the NTETC Software Sector is important in providing appropriate type evaluation criteria for 

software-based weighing or measuring device based on specifications, tolerances and technical requirements of 

NIST Handbook 44, Specifications, Tolerances, and Other Technical Requirements for Weighing and Measuring 

Devices, Section 1.10. General Code, Section 2 for weighing devices, Section 3 for liquid and vapor measuring 

devices, and Section 5 for taximeters, grain analyzers, and multiple dimension measuring devices. The Sector’s 

recommendations are presented to the National Type Evaluation Program (NTEP) Committee each January for 

approval and inclusion in NCWM Publication 14, Technical Policy, Checklists, and Test Procedures, for national 

type evaluation. 

The Sector is also called upon occasionally for technical expertise in addressing difficult NIST Handbook 44 issues 

on the agenda of the National Conference on Weights and Measures (NCWM) Specifications and Tolerances (S&T) 

Committee. Sector membership includes industry, NTEP laboratory representatives, technical advisors, and the 

NTEP Administrator. Meetings are held annually, or as needed and are open to all NCWM members and other 

registered parties. 

Proposed revisions to the handbook(s) are shown as follows: 1) deleted language is indicated with a bold face font 

using strikeouts (e.g., this report), 2) proposed new language is indicated with an underscored bold faced font

(e.g., new items), and 3) nonretroactive items are identified in italics. There are instances where the Sector will use 

red text and/or highlighted text to bring emphasis to text that requires additional attention. When used in this report, 

the term “weight” means “mass.” 

Note: It is the policy of the National Institute of Standards and Technology (NIST) to use metric units of measurement in 

all of its publications; however, recommendations received by NCWM technical committees and regional weights and 

measures associations have been printed in this publication as submitted. Therefore, the report may contain references in 

inch-pound units. 

Table A 

Table of Contents 

Title of Content Page NTEP E

INTRODUCTION ....................................................................................................................................................... 1

WELCOME/INTRODUCTIONS .............................................................................................................................. 2

STATUS REPORTS – RELATED NCWM AND INTERNATIONAL ACTIVITY ............................................. 2

CARRY-OVER ITEMS .............................................................................................................................................. 3

1. Software Identification/Markings ................................................................................................................ 3

2. Identification of Certified Software ............................................................................................................. 6

3. Software Protection/Security ..................................................................................................................... 10

4. Software Maintenance and Reconfiguration .............................................................................................. 14

5. NTEP Application for Software and Software-based Devices .................................................................. 16

6. Training of Field Inspectors ....................................................................................................................... 17
NTEP Committee 2014 Final Report 

Appendix E – 2013 NTEP Software Sector Summary 

NTEP - E2 

NEW ITEMS .............................................................................................................................................................. 20

7. Next Meeting ............................................................................................................................................. 20

8. 2013 NCWM Interim Meeting Report ....................................................................................................... 21

9. 2013 International Report .......................................................................................................................... 21

10. 360-7 D Appendix D – Definitions: Remote Configuration Capability .................................................... 21 

Appendix 

A. Appendix – List of Acceptable Menu Text/Icons for Identification of Certificate Number ............... E / A1

Table B 

Glossary of Acronyms and Terms 

Acronym Term Acronym Term 

BIML International Bureau of Legal Metrology OIML International Organization of Legal 

Metrology 

CC Certificate of Conformance OWM Office of Weights and Measures 

EPO Examination Procedure Outline PDC Professional Development Committee 

GMMs Grain Moisture Meters PDC Professional Development Committee 

NCWM National Conference on Weights and 

Measures 

S&T Specifications and Tolerances 

Committee 

NTEP National Type Evaluation Program SMA Scale Manufactures Association 

NTETC National Type Evaluation Technical 

Committee 

WELMEC European Cooperation in Legal 

Metrology 

Details of All Items 

(In order by Reference Key) 

WELCOME/INTRODUCTIONS 

The Chair would like to welcome new individuals that have joined the NTETC Software Sector since the last 

meeting. Please welcome: 

 Eric Morabito, New York Bureau of Weights & Measures 

 Gary Benjamin, NCR Corporation 

STATUS REPORTS – RELATED NCWM AND INTERNATIONAL ACTIVITY 

Attendees of the 2013 NCWM Interim Meeting will be asked to share any relevant comments or discussion that took 

place during the open hearings or NCWM Standards and Tolerances (S&T) Committee working sessions. 

Mr. Jim Truex was the only Sector attendee at the Interim Meeting. He doesn’t recall any comments on the floor. 

After the hearings, he had a brief discussion with the S&T Committee, to little effect. 
NTEP Committee 2014 Final Report 

Appendix E – 2013 NTEP Software Sector Summary 

NTEP - E3 

Dr. Ambler Thompson, NIST, Office of Weights and Measures (OWM), will provide a synopsis of international 

activity that relates to the work of the Sector. 

The new proposed revision of OIML has increased the risk classifications. The next CIML meeting is set for 

October. 

CARRY-OVER ITEMS 

1. Software Identification/Markings 

Source: 

NTETC Software Sector 

Background: 

Since its inception the Sector has wrestled with the issue of software identification and marking requirements. See 

the 2012 Software Sector Meeting Summary and the 2013 Interim Meeting S&T Agenda Item 360-2 for more 

background on this item. 

NIST, OWM had been adding items to the S&T Agendas that confused matters since the perception was that this 

Sector had contributed to this input. Most of the confusion arose in the 1990s, due to some items being approved, 

and others, such as the definitions for “Built-for-Purpose” and “Not-Built-for -Purpose,” not being approved. 

Mr. Truex, NTEP Administrator, discussed the difficulty there has been in coming to a consensus on these issues 

with a representative of the NTEP Committee. Suggestions from NTEP to come to some resolution has been to 

write an article for the newsletter (which Mr. Bliss, Mettler-Toledo, LLC, had already done, to no effect), sending a 

questionnaire to the NTEP community, asking what they would like to see, and sending a representative from this 

Sector to the S&T Committee. 

Mr. Roach (California Division of Measurement Standards) is concerned that some people may want to interpret GS.1.(c) as requiring a serial number for software. Mr. Lewis (Rice Lake Weighing Systems, Inc.) pointed out that 

the computer the software was running on could have the serial number, not the software itself. That shouldn’t 

matter, regardless. 

Mr. Bliss (Mettler-Toledo, LLC) pointed out that the terminology in G-S.1. “All equipment,” could be interpreted to 

mean that it doesn’t apply to software. It was proposed that G-S.1.(c) be amended to add “and software.” Mr. Bliss 

suggested submitting a document explaining the reasoning behind the proposed changes, rather than assume the text 

is self-explanatory. Making a presentation to the various Committees on the subject in addition would be beneficial 

as well. If a document is written, perhaps the examples given in G-S.1.(d)(3)(a) can be eliminated. “Metrologically 

significant” isn’t explicitly defined, but it’s been used since time immemorial. 

Attempts to modify G-S.1.1. have been controversial, both in this meeting and in other committees. Unfortunately, 

there has been little constructive feedback from the other Committees. It would probably be easier to incorporate 

specific examples given in G-S.1.1(b)3 in NCWM Publication 14. After some discussion, the previously proposed 

language was modified slightly to address some of the concerns received via feedback from other Sectors and 

interested parties: 

NIST Handbook 44 – Proposed Changes:

G-S.1. Identification. – All equipment, except weights and separate parts necessary to the measurement 

process but not having any metrological effect, shall be clearly and permanently marked for the purposes of 

identification with the following information: 

(a) the name, initials, or trademark of the manufacturer or distributor; 
NTEP Committee 2014 Final Report 

Appendix E – 2013 NTEP Software Sector Summary 

NTEP - E4 

(b) a model identifier that positively identifies the pattern or design of the device; 

(1) The model identifier shall be prefaced by the word “Model,” “Type,” or “Pattern.” These terms 

may be followed by the word “Number” or an abbreviation of that word. The abbreviation for the 

word “Number” shall, as a minimum, begin with the letter “N” (e.g., No or No.). The 

abbreviation for the word “Model” shall be “Mod” or “Mod.” Prefix lettering may be initial 

capitals, all capitals, or all lowercase. 

[Nonretroactive as of January 1, 2003] 

(Added 2000) (Amended 2001) 

(c) a nonrepetitive serial number, except for equipment with no moving or electronic component parts and

not-built-for-purpose software-based software devices software;

[Nonretroactive as of January 1, 1968] 

(Amended 2003) 

(1) The serial number shall be prefaced by words, an abbreviation, or a symbol, that clearly identifies 

the number as the required serial number. 

[Nonretroactive as of January 1, 1986] 

(2) Abbreviations for the word “Serial” shall, as a minimum, begin with the letter “S,” and 

abbreviations for the word “Number” shall, as a minimum, begin with the letter “N” (e.g., S/N, 

SN, Ser. No., and S. No.). 

[Nonretroactive as of January 1, 2001] 

(d) the current software version or revision identifier for not-built-for-purpose software-based 

electronic devices, which shall be directly linked to the software itself; 

[Nonretroactive as of January 1, 2004] 

(Added 2003) (Amended 20XX)

(1) The version or revision identifier shall be prefaced by words, an abbreviation, or a symbol, that 

clearly identifies the number as the required version or revision. 

[Nonretroactive as of January 1, 2007] 

(Added 2006) 

(2) Abbreviations for the word “Version” shall, as a minimum, begin with the letter “V” and may be 

followed by the word “Number.” Abbreviations for the word “Revision” shall, as a minimum, 

begin with the letter “R” and may be followed by the word “Number.” The abbreviation for the 

word “Number” shall, as a minimum, begin with the letter “N” (e.g., No or No.). 

[Nonretroactive as of January 1, 2007] 

(Added 2006) 

(3) The version or revision identifier shall be accessible via the display. Instructions for displaying 

the version or revision identifier shall be described in the CC. As an exception, permanently 

marking the version or revision identifier shall be acceptable under the following conditions: 

(a) The user interface does not have any control capability to activate the indication of the 

version or revision identifier on the display, or the display does not technically allow the 

version or revision identifier to be shown (analog indicating device or electromechanical 

counter,) or 

(b) the device does not have an interface to communicate the version or revision identifier. 

(e) an NTEP CC number or a corresponding CC Addendum Number for devices that have a CC. 

(1) The CC Number or a corresponding CC Addendum Number shall be prefaced by the terms 

“NTEP CC,” “CC,” or “Approval.” These terms may be followed by the word “Number” or an 
NTEP Committee 2014 Final Report 

Appendix E – 2013 NTEP Software Sector Summary 

NTEP - E5 

abbreviation of that word. The abbreviation for the word “Number” shall, as a minimum, begin 

with the letter “N” (e.g., No or No.) 

[Nonretroactive as of January 1, 2003] 

The required information shall be so located that it is readily observable without the necessity of the 

disassembly of a part requiring the use of any means separate from the device. 

(Amended 1985, 1991, 1999, 2000, 2001, 2003, and, 2006 and 201X) 

G-S.1.1. Location of Marking Information for Not-Built-For-Purpose all Software-Based Devices. – For

not-built-for-purpose, software-based devices, either: 

(a) The required information in G-S.1. Identification. (a), (b), (d), and (e) shall be permanently marked or 

continuously displayed on the device; or 

(b) The CC Number shall be: 

(1) permanently marked on the device; 

(2) continuously displayed; or 

(3) accessible through an easily recognized menu and, if necessary, a submenu. Examples of menu 

and submenu identification include, but are not limited to, “Help,” “System Identification,” 

“G-S.1. Identification,” or “Weights and Measures Identification.” 

Note: For (b), clear instructions for accessing the information required in G-S.1. (a), (b), and (d) shall be listed 

on the CC, including information necessary to identify that the software in the device is the same type that was 

evaluated. 

[Nonretroactive as of January 1, 2004] 

(Added 2003) (Amended 2006 and 20XX) 

The new language in G-S.1.1. reflects that the sector reached consensus on the following positions: 

 The software version/revision should (with very few exceptions – see D-31 5.1.1.) be accessible via the 

user interface. 

 The means by which the software version is accessed must be described in the Certificate of Conformance 

(CC). 

The Sector promoted this item following the meeting via several means to try and address the concerns of other 

interested parties. A presentation was generated and shared with the S.M.A. at their meeting. The regions had 

access to this information, as it was posted on the NCWM website. Unfortunately, based on the comments in the 

2013 NCWM Publication 15 Item 360-2, some regions were not aware that this information had been provided. 

During the 2013 NCWM Interim Meeting, no comments were received relative to this item during the Open 

Hearings. In considering the item, the Committee questioned whether or not the Software Sector was still actively 

working the item. It was reported that the Software Sector believed they had developed the item as much as 

possible, yet the different stakeholders affected by the proposal could not agree on the changes that the Sector had 

proposed. Based upon that update, the Committee agreed to add to its report a request that the Software Sector work 

with the Weighing Sector and Measuring Sector to identify which portions of the proposal need to be modified in 

order that they might be accepted by the entire community. The Committee acknowledges and appreciates the 

efforts of the Software Sector and looks forward to being able to consider a proposal that addresses both the 

identification of software and how it may be accessed. 
NTEP Committee 2014 Final Report 

Appendix E – 2013 NTEP Software Sector Summary 

NTEP - E6 

Discussion: 

Since the 2012 meeting, the Sector has attempted to promote this item via several means to try and address the 

concerns of other interested parties. A presentation was generated and shared with the S.M.A. at their 2012 meeting. 

Most of the regions had access to this information prior to their meetings, as it was posted on the NCWM website. 

Unfortunately, based on the comments in the 2013 NCWM Publication 15, Item 360-2, some regions were not 

aware that this information had been made available. 

In addition, it was noted that it may be desirable to evaluate options that would lead to fully eliminating GS-1.1. It 

was noted that this would be a more invasive modification to the existing Handbook and perhaps should be put off 

until the first step of addressing software in all devices (not just standalone) was accomplished. 

Conclusion: 

The Sector considers this item sufficiently developed. The one response to our request for review/comment that 

contained negative feedback was undeniably vague and non-constructive. The issue seems to be more one of 

communication/understanding than disagreement with the intent or wording. We may want to consider more direct 

methods, that is, designating a representative to address the regional groups or other Sectors at their meetings. The 

annual meeting may be an appropriate venue for a presentation.

To move this forward, someone should address the regional groups. There are five to six potential venues for 

presentations. The last slide from the current presentation should be eliminated, to avoid confusing matters, for the 

time being. The two regional meetings in the fall (Western and Southern) and the interim meeting are probably 

more critical than the ones in May. Dr. Thompson was asked to relay that we have a presentation available and 

would like to push our proposal as a Voting Item in 2014. To be part of the January 2014 Annual S&T committee’s 

hearings/agenda, this needs to be brought to Mr. Rick Harshman’s attention. Dr. Thompson volunteered to speak 

with him. 

After removing the “and inseparably” terminology from the proposal, the concerns on the possibility of controversy 

were reduced. 

The Sector’s opinion on the interpretation of “directly linked” is that it means that you can’t change the 

version/revision without changing the software. 

It was recommended that a couple examples be added to the current slide presentation, to illustrate the intent of the 

proposed changes. One example might be supermarket-specific software designed to run upon a cash register. 

Another example might be, after a software change, noting that the new software version/revision number is no 

longer the same, and the operator was not prompted to enter a version/revision number. 

Note: The text in red is a modification in the proposal made this year – the new text was inserted to address our 

Agenda Item 2. Upon the suggestion of NIST, OWM, the modifications to NIST Handbook 44 in these items were 

combined to avoid having to forward another proposal to modify Handbook 44 simultaneously or in the immediate 

future. 

2. Identification of Certified Software 

Source: 

NTETC Software Sector 

Background: 

This item originated as an attempt to answer the question “How does the field inspector know that the software 

running in the device is the same software evaluated and approved by the lab?” In previous meetings it was shown 

that the international community has addressed this issue (both WELMEC and OIML). 

From WELMEC 7.2:
NTEP Committee 2014 Final Report 

Appendix E – 2013 NTEP Software Sector Summary 

NTEP - E7 

Required Documentation: 

The documentation shall list the software identifications and describe how the software identification is created, 

how it is inextricably linked to the software itself, how it may be accessed for viewing, and how it is structured 

in order to differentiate between version changes with and without requiring a type approval. 

From OIML D-31: 

The executable file “tt100_12.exe” is protected against modification by a checksum. The value of checksum as 

determined by algorithm XYZ is 1A2B3C. 

Previous discussions have included a listing of some additional examples of possible valid methods (not limiting): 

 CRC (cyclical redundancy check) 

 Checksum 

 Inextricably Linked version no. 

 Encryption 

 Digital Signature 

Is there some method to give the weights and measures inspector information that something has changed? 

Yes, the Category III Audit Trail or other means of sealing. 

How can the weights and measures inspector identify an NTEP Certified version? 

They can’t, without adding additional requirements like what is described here, in conjunction with including the 

identifier on the CC).

The Sector believes that we should work towards language that would include a requirement similar to the 

International Organization of Legal Metrology (OIML) requirement in NIST Handbook 44. It is also the opinion of 

the Sector that a specific method should not be defined; rather the manufacturer should utilize a method and 

demonstrate the selected identification mechanism is suitable for the purpose. It is not clear from the discussion 

where such proposed language might belong. 

NTEP strongly recommends that metrological software be separated from non-metrological software for ease of 

identification and evaluation. 

From OIML: 

Separation of software parts – All software modules (programmes, subroutines, objects etc.) that perform 

metrologically significant functions or that contain metrologically significant data domains form the 

metrologically significant software part of a measuring instrument (device or sub-assembly). The conformity 

requirement applies to all parts and parts shall be marked according to Section G-S-X.X. 

If the separation of the software is not possible or needed, then the software is metrologically significant as a 

whole. 

(Segregation of parameters is currently allowed – see table of sealable parameters) 

Initial draft proposed language: (G-S.1.1?) 

NIST Handbook 44 (This has been written into G-S.1.(d)(3): Identification of Certified Software: 

Software-based electronic devices shall be designed such that the metrologically significant software is 

clearly identified by the version or revision number. The identification, and this identification of the 

software shall be inextricably directly and inseparably linked to the software itself. The version or 

revision number may consist of more than one part, but at least one part shall be dedicated to the 

metrologically significant software. 
NTEP Committee 2014 Final Report 

Appendix E – 2013 NTEP Software Sector Summary 

NTEP - E8 

From NCWM Publication 14: 

Identification of Certified Software: 

Note: Manufacturers may choose to separate metrologically significant software from non-metrologically 

significant software. Separation would allow the revision of the non-metrological portion without the need for 

further evaluation. In addition, non-metrologically significant software may be updated on devices without 

breaking a seal, if so designed. Separation of software requires that all software modules (programs, 

subroutines, objects etc.) that perform metrologically significant functions or that contain metrologically 

significant data domains form the metrologically significant software part of a measuring instrument (device or 

sub-assembly). If the separation of the software is not possible or needed, then the software is metrologically 

significant as a whole. The conformity requirement applies to all parts and parts shall be marked 

according to Section G-S-X.X.

The manufacturer must describe and possibly demonstrate how the version or revision identifier is directly and 

inseparably linked to the metrologically significant software. Where the version revision identifier is comprised 

of more than one part, the manufacturer shall describe which portion represents the metrological significant 

software and which does not. 

From OIML D-31: 

Legally relevant software of a measuring instrument/electronic device/sub-assembly shall be clearly identified 

with the software version or another token. The identification may consist of more than one part but at least one 

part shall be dedicated to the legal purpose. 

The identification shall be inextricably linked to the software itself and shall be presented or printed on 

command or displayed during operation or at start up for a measuring instrument that can be turned off and on 

again. If a sub-assembly/an electronic device has neither display nor printer, the identification shall be sent via 

a communication interface in order to be displayed/printed on another sub-assembly/electronic device. 

The first sentence of the first paragraph above is already addressed in NIST Handbook 44’s marking requirements. 

In 2010, the Sector recommended the following change to NIST Handbook 44, General Code: G-S.1(d) to add a new 

subsection (3): 

(d) the current software version or revision identifier for not-built-for-purpose software-based electronic

devices; 

[Nonretroactive as of January 1, 2004] 

(Added 2003) (Amended 20XX) 

(1) The version or revision identifier shall be prefaced by words, an abbreviation, or a symbol, that 

clearly identifies the number as the required version or revision. 

[Nonretroactive as of January 1, 2007] 

(Added 2006) 

(2) Abbreviations for the word “Version” shall, as a minimum, begin with the letter “V” and may be 

followed by the word “Number.” Abbreviations for the word “Revision” shall, as a minimum, begin 

with the letter “R” and may be followed by the word “Number.” The abbreviation for the word 

“Number” shall, as a minimum, begin with the letter “N” (e.g., No or No.). 

[Nonretroactive as of January 1, 2007] 

(Added 2006) 
NTEP Committee 2014 Final Report 

Appendix E – 2013 NTEP Software Sector Summary 

NTEP - E9 

(3) The version or revision identifier shall be directly and inseparably linked to the software itself. 

The version or revision identifier may consist of more than one part, but at least one part shall 

be dedicated to the metrologically significant software. 

[Nonretroactive as of January 1, 201X] 

(Added 20XX) 

Also the Sector recommended the following information be added to NCWM Publication 14 as 

explanation/examples: 

 Unique identifier must be displayable/printable on command or during operation, etc. 

 At a minimum, a version/revision indication (1.02.09, rev 3.0 a, etc.). Could also consist of/contain 

checksum, etc. (crc32, for example). 

There was some additional discussion on this item regarding where this new requirement was best 

located. It was suggested that the first sentence of G-S.1.(d)(3) could be added as a clause to the base 

paragraph G-S.1.(d) text, for example, “the current software version or revision identifier for not-built-forpurpose software-based devices, which shall be directly and inseparably linked to the software itself.”.

It also was suggested that the second sentence in G-S.1.(d)(3) might be more suitable for NCWM Publication 14, as 

it describes more “how” than “what” the requirement entails. 

In addition, the Sector considered the following information to be added to NCWM Publication 14 as 

explanation/examples: 

 The current software identifier must be displayable/printable on command during operation (or made 

evident by other means deemed acceptable by G-S.1.). 

 At a minimum, the software identifier must include a version/revision indication (1.02.09, rev 3.0 a, etc). It 

could also consist of/contain checksum, etc. (crc32, for example). 

 The version or revision identifier may consist of more than one part, but at least one part shall be dedicated 

to the metrologically significant software. 

Other questions still outstanding: 

 If we allow hard-marking of the software identifier (the Sector has wavered on this in the past), does the 

above wording then imply that some mechanical means is required (i.e., physical seal) to ”inseparably link” 

the identifier to the software? 

 If a device is capable of doing so, does it still have to be able to display, print or communicate the identifier 

somehow, even if it is hard-marked? 

At the 2012 NTETC Software Sector Meeting, there was some discussion as to where the terminology regarding 

inextricably linking the software version or revision to the software itself belonged. At the moment, it is not 

incorporated in the proposed text for G-S.1. NCWM Publication 14 may be a better option for the time being. This 

would be another item that would benefit from further explanation in a supplementary document. 

Several Sector members were of the opinion that attempting to make this change at the same time as the earlier 

changes might be a difficult sell. Mr. Truex, NTEP Administrator, reiterated the necessity of baby steps. 

In 2012, the Sector thus recommended adding the following to NCWM Publication 14 and forward to NTETC 

Weighing, Measuring, Grain Analyzer Sectors for feedback: 

Identification of Certified Software: 

Note: Manufacturers may choose to separate metrologically significant software from non-metrologically 

significant software. Separation would allow the revision of the non-metrological portion without the need for 
NTEP Committee 2014 Final Report 

Appendix E – 2013 NTEP Software Sector Summary 

NTEP - E10 

further evaluation. In addition, non-metrologically significant software may be updated on devices without 

breaking a seal, if so designed. Separation of software requires that all software modules (programs, 

subroutines, objects etc.) that perform metrologically significant functions or that contain metrologically 

significant data domains form the metrologically significant software part of a measuring instrument (device or 

sub-assembly). If the separation of the software is not possible or needed, then the software is metrologically 

significant as a whole. The conformity requirement applies to all parts and parts shall be marked according to 

Section G-S-X.X. 

The manufacturer must describe and possibly demonstrate how the version or revision identifier is directly and 

inseparably linked to the metrologically significant software. Where the version revision identifier is comprised 

of more than one part, the manufacturer shall describe which portion represents the metrological significant 

software and which does not. 

Discussion: 

The Measuring Sector reviewed this item and had no feedback other than a statement that they support the 

continuing/ongoing efforts of this sector. The Weighing Sector summary mentioned that no one opted to provide 

comment. They agreed to take no further action on this item, pending further action from the Software Sector. This 

was specifically in reference to the accepted symbols. 

For the time being, Jim Truex recommended that we not attempt to provide a definition for “software-based device.” 

We discussed the possibility of combining this change with the first agenda item, which had been attempted in 

previous years. Alternatively, if the NIST Handbook 44 changes from agenda Item 1 are made, this agenda item 

could be addressed in NCWM Publication 14. 

Conclusion:

After further discussion, the wording in G-S.1.(d) under agenda item 1 was changed. Agenda Item 2 will remain; 

however, it will address potential changes to NCWM Publication 14 and contain no suggested modifications to 

NIST Handbook 44. (See changes and conclusion under agenda Item 1 for further details.) 

The Sector Chair volunteered to review the existing slide presentation detailing the purpose of these changes, to 

ensure that it accurately reflects this information. 

The list of acceptable menu text and symbols in Appendix A are intended to assist the labs in finding the 

certification number. The Sector noticed no action by the Sectors had been taken when this list was circulated for 

comment. We would like to remind them that we would like to have it reviewed. We feel that this belongs in, for 

example, the Weighing Device Publication 14, page DES-22, Section 3; the Belt-Conveyor Scales, page BCS-10, 

Section 8.7; the Measuring Devices, page LMD-21, Section 1.6; the Grain Moisture Meter, page GMM-14, 

Section 1 (G.S.1.); and Near Infrared Grain Analyzers, page NIR-8, Section 1 (G.S.1.). 

3. Software Protection/Security 

Source: 

NTETC Software Sector 

Background: 

The Sector agreed that NIST Handbook 44 already has audit trail and physical seal, but these may need to be 

enhanced. 

From the WELMEC Document: 

Protection against accidental or unintentional changes: 

Metrologically significant software and measurement data shall be protected against accidental or unintentional 

changes. 
NTEP Committee 2014 Final Report 

Appendix E – 2013 NTEP Software Sector Summary 

NTEP - E11 

Specifying Notes: 

Possible reasons for accidental changes and faults are: unpredictable physical influences, effects caused by user 

functions and residual defects of the software even though state-of-the-art development techniques have been 

applied. 

This requirement includes consideration of: 

a) Physical influences: Stored measurement data shall be protected against corruption or deletion when a 

fault occurs or, alternatively, the fault shall be detectable. 

b) User functions: Confirmation shall be demanded before deleting or changing data. 

c) Software defects: Appropriate measures shall be taken to protect data from unintentional changes that 

could occur through incorrect program design or programming errors, e.g. plausibility checks. 

Required Documentation: 

The documentation should show the measures that have been taken to protect the software and data against 

unintentional changes. 

Example of an Acceptable Solution: 

 The accidental modification of software and measurement data may be checked by calculating a checksum 

over the relevant parts, comparing it with the nominal value and stopping if anything has been modified. 

 Measurement data are not deleted without prior authorization, for example, a dialogue statement or window 

asking for confirmation of deletion. 

 For fault detection see also Extension I. 

The Sector continued to develop a proposed checklist for NCWM Publication 14. The numbering will still need to 

be added. This is based roughly on R 76-2 checklist and discussions beginning as early as the October 2007 NTETC 

Software Sector Meeting. The information requested by this checklist is currently voluntary; however, it is 

recommended that applicants comply with these requests or provide specific information as to why they may not be 

able to comply. Based on this information, the checklist may be amended to better fit with NTEP's need for 

information and the applicant's ability to comply. 

The California, Maryland, and Ohio laboratories agreed to use this checklist on one of the next devices they have in 

the lab and report back to the sector on what the problems may be. In February 2011, the North Carolina laboratory 

was also given a copy of the checklist to try. 

 
NTEP Committee 2014 Final Report 

Appendix E – 2013 NTEP Software Sector Summary 

NTEP - E12 

1. Devices with Embedded Software TYPE P (aka built-for-purpose) 

1.1. Declaration of the manufacturer that the software is used in a fixed 

hardware and software environment. AND

 Yes No N/A 

1.2. Cannot be modified or uploaded by any means after securing/verification. Yes No N/A 

Note: It is acceptable to break the "seal" and load new software, audit trail is 

also a sufficient seal. 

1.3. The software documentation contains: 

1.3.1. Description of all functions, designating those that are 

considered metrologically significant. 

 Yes No N/A 

1.3.2. Description of the securing means (evidence of an intervention). Yes No N/A 

1.3.3. Software Identification, including version / revision Yes No N/A 

1.3.4. Description how to check the actual software identification. Yes No N/A 

1.4. The software identification is: 

1.4.1. Clearly assigned to the metrologically significant software and

functions. 

 Yes No N/A 

1.4.1. Description how to check the actual software identification. Yes No N/A 

1.4.2. Provided by the device as documented. Yes No N/A 

1.4.3. Directly linked to the software itself. Yes No N/A 

2. Personal Computers, Instruments with PC Components, and Other Instruments, Devices, Modules, and 

Elements with Programmable or Loadable Metrologically Significant Software TYPE U (aka not builtfor-purpose) 

2.1. The metrologically significant software is: 

2.1.1. Documented with all relevant (see below for list of documents) 

information. 

 Yes No N/A 

2.1.2. Protected against accidental or intentional changes. Yes No N/A 

2.2. Evidence of intervention (such as, changes, uploads, circumvention) is 

available until the next verification / inspection (e.g., physical seal, 

Checksum, Cyclical Redundancy Check (CRC), audit trail, etc. means of 

security). 

 Yes No N/A 

3. Software with Closed Shell (no access to the operating system and/or programs possible for the user) 

3.1. Check whether there is a complete set of commands (e.g., function keys or 

commands via external interfaces) supplied and accompanied by short 

descriptions. 

 Yes No N/A 

3.2. Check whether the manufacturer has submitted a written declaration of the 

completeness of the set of commands. 

 Yes No N/A 

4. Operating System and/or Program(s) Accessible for the User 

4.1. Check whether a checksum or equivalent signature is generated over the 

machine code of the metrologically significant software (program 

module(s) subject to legal control Weights and Measures jurisdiction and 

type-specific parameters). 

 Yes No N/A 
NTEP Committee 2014 Final Report 

Appendix E – 2013 NTEP Software Sector Summary 

NTEP - E13 

4.2. Check whether the metrologically significant software will detect and act 

upon any unauthorized alteration of the metrologically significant 

software using simple software tools (e.g., text editor). 

 Yes No N/A 

5. Software Interface(s) 

5.1. Verify the manufacturer has documented: 

5.1.1. The program modules of the metrologically significant software 

are defined and separated. 

 Yes No N/A 

5.1.2. The protective software interface itself is part of the 

metrologically significant software. 

 Yes No N/A 

5.1.3. The functions of the metrologically significant software that can 

be accessed via the protective software interface. 

 Yes No N/A 

5.1.4. The parameters that may be exchanged via the protective 

software interface are defined. 

 Yes No N/A 

5.1.5. The description of the functions and parameters are conclusive 

and complete. 

 Yes No N/A 

5.1.6. There are software interface instructions for the third-party 

(external) application programmer. 

 Yes No N/A 

The Maryland laboratory had particular questions regarding 3.1 and 5.1. The information for 3.1 could be acquired 

from an operator’s manual, a training video, or in-person training. The items in 5.1 were confusing to the 

evaluators. The terminology is familiar to software developers, but not necessarily others. It was indicated that 

manufacturers were typically quick to return the filled out questionnaire, but he didn’t know how his laboratory was 

supposed to verify that it was true. Generally, the laboratories wouldn’t be expected to verify things to that level. 

For example, if the manufacturer states that a checksum is used to ensure integrity, the laboratories wouldn’t be 

expected to evaluate the algorithm used. 

The intent was to see whether the manufacturer had at least considered these issues, not for evaluators to become 

software engineers. Perhaps a glossary or descriptive paragraphs might be added to assist the evaluators for if the 

manufacturer has questions for the evaluators. 

OIML makes use of supplementary documents to explain the checklist they use. Below are links: 

http://www.oiml.org/publications/D/D031-e08.pdf 

http://www.welmec.org/latest/guides/72.html 

http://www.welmec.org/fileadmin/user_files/publications/2-3.pdf

WELMEC document 2.3 is the original source for our checklist, but it’s been significantly revised and simplified. 

Mr. Payne, Maryland Department of Agriculture, is going to review the other documents and come up with some 

suggestions for the checklist. Mr. Roach, California Division of Measurement Standards, is going to begin using the 

checklist. The international viewpoint is that any device running an operating system is considered to be Type U. 

Mr. Roach mentioned that they’re having lots of problems with “skimmers” stealing PIN’s. Is there some way they 

can detect this? 

Mr. Lewis, Rice Lake Weighing Systems, Inc., mentioned that he liked Measurement Canada’s website. When 

answering similar questions, different pages would appear, based on answers to those questions: 

http://www.ic.gc.ca/eic/site/mc-mc.nsf/eng/lm00573.html 

At the 2011 NTETC Software Sector Meeting, the laboratories were polled to obtain any feedback on the use of the 

checklist. Maryland attempted to use this checklist a few times. They had some difficulty obtaining answers from 

the manufacturers because the individual(s) interacting with the Maryland evaluator didn’t always have the required 

information on-hand. More experience in using the checklist will help determine what needs to be revised. 
NTEP Committee 2014 Final Report 

Appendix E – 2013 NTEP Software Sector Summary 

NTEP - E14 

It was suggested that the checklist could be sent to manufacturers for their feedback as well, with the stipulation that 

it a completely voluntary exercise and purely informational at this point. The laboratories will coordinate with 

willing manufacturers to obtain feedback. 

Work is ongoing on this item with the intent that it eventually will be incorporated as a checklist in NCWM 

Publication 14; again the laboratories are requested to try utilizing this checklist for any evaluations on softwarebased electronic devices. 

The checklist has been reviewed with an eye to making its terminology clearer to laboratories. Some examples and 

clarifications have been added as shown in the discussion section of this item. The revised checklist will be 

distributed to the laboratories for additional review. Maryland and California laboratories agreed to use the checklist 

on a trial basis. 

Discussion: 

Over the past year, attempts to use the current checklist did not meet with many difficulties. The checklists were 

given to the manufacturers to fill out, and that seemed to work rather well. Minor modifications (in red above) were 

made to clarify certain confusing areas or eliminate redundancy. 

Conclusion: 

The next step will be to forward it to the four sectors; we can report that the labs have tried using it on a trial basis 

and we’re ready to recommend it for NCWM Publication 14 with the modification suggested here, such as the 

removal of the Type P/Type U wording. 

4. Software Maintenance and Reconfiguration 

Source: 

NTETC Software Sector 

Background: 

After the software is completed, what do the manufacturers use to secure their software? The following items were 

reviewed by the sector. Note agenda Item 3 also contains information on Verified and Traced updates and Software 

Log.

1. Verify that the update process is documented. (OK) 

2. For traced updates, installed Software is authenticated and checked for integrity. 

Technical means shall be employed to guarantee the authenticity of the loaded software (i.e., that it originates 

from the owner of the type approval certificate). This can be accomplished (e.g, by cryptographic means like 

signing). The signature is checked during loading. If the loaded software fails this test, the instrument shall 

discard it and either use the previous version of the software or become inoperative. 

Technical means shall be employed to guarantee the integrity of the loaded software (i.e. that it has not been 

inadmissibly changed before loading). This can be accomplished in other words by adding a checksum or hash 

code of the loaded software and verifying it during the loading procedure. If the loaded software fails this test, 

the instrument shall discard it and either use the previous version of the software or become inoperative. 

Examples are not limiting or exclusive. 

3. Verify that the sealing requirements are met. 

The Sector asked, “What sealing requirements are we talking about?” 

This item is only addressing the software update, it can be either verified or traced. It is possible that there are 

two different security means, one for protecting software updates (software log) and one for protecting the other 
NTEP Committee 2014 Final Report 

Appendix E – 2013 NTEP Software Sector Summary 

NTEP - E15 

metrological parameters (Category I, II, or III method of sealing). Some examples provided by the Sector 

members include but are not limited to: 

 Physical seal, software log 

 Category III method of sealing can contain both means of security 

4. Verify that if the upgrade process fails, the device is inoperable or the original software is restored. 

The question before the group is, can this be made mandatory? 

The manufacturer shall ensure by appropriate technical means (e.g., an audit trail) that traced updates of 

metrologically significant software are adequately traceable within the instrument for subsequent verification 

and surveillance or inspection. This requirement enables inspection authorities, which are responsible for the 

metrological surveillance of legally controlled instruments, to back-trace traced updates of metrologically 

significant software over an adequate period of time (that depends on national legislation). The statement in 

italics will need to be reworded to comply with U.S. weights and measures requirements. 

The Sector agreed that the two definitions below for Verified Update and Traced Update were acceptable. 

Verified Update 

A verified update is the process of installing new software where the security is broken and the device must be 

re-verified. Checking for authenticity and integrity is the responsibility of the owner/user. 

Traced Update 

A traced update is the process of installing new software where the software is automatically checked for 

authenticity and integrity, and the update is recorded in a software update log or audit trail. 

Note: It’s possible that the Philosophy of Sealing section of NCWM Publication 14 may already address the above 

IF the definitions of Verified and Traced Updates (and the statement below) were to be added. The contrary 

argument was that it may be better to be explicit). 

Use of a Category 3 audit trail is required for a Traced Update. A log entry representing a traced 

software update shall include the software identification of the newly installed version. 

The Sector recommended consolidating the definitions with the above statement thus: 

Verified Update 

A verified update is the process of installing new software where the security is broken and the device must be 

re-verified. Checking for authenticity and integrity is the responsibility of the owner/user. 

Traced Update 

A traced update is the process of installing new software where the software is automatically checked for 

authenticity and integrity, and the update is recorded in a software update log or Category 3 audit trail. The 

audit trail entry shall include the software identification of the newly installed version. 

In 2012, the Sector recommended that as a first step, the following be added to NCWM Publication 14: 

The updating of metrologically significant software, including software that checks the authenticity 

and integrity of the updates, shall be considered a sealable event. 

Mr. Truex, NTEP Administrator, indicated his opinion that the above sentence is unnecessary since it’s self-evident. 

It was agreed by the group however to ask the other sectors for feedback on the value of this addition. 

Though the Sector is currently considering only the single sentence be incorporated into NCWM Publication 14 for 

the time being, ultimately, the Sector may wish to advance the remaining language of the original item submission. 
NTEP Committee 2014 Final Report 

Appendix E – 2013 NTEP Software Sector Summary 

NTEP - E16 

Discussion:

The Sector had no information indicating that the other sectors had yet been approached for feedback on the value of 

the addition of the proposed sentence. 

Conclusion: 

This sector would like the other sectors to evaluate this for inclusion in Publication 14.We’d also like to include 

some description indicating that an existing audit trail should be protected during a software update, though that may 

already be a requirement. This does appear to be addressed in the Requirements for Metrological Audit Trails 

Appendices in NCWM Publication 14. 

5. NTEP Application for Software and Software-based Devices 

Source: 

NTETC Software Sector 

Background/Discussion: 

The purpose of initiating this item was to identify issues, requirements, and processes for type approving Type U 

device applications. It was suggested that it may be useful to the labs to devise a separate submission form for 

software for Type U devices. What gets submitted? What requirements and mechanisms for submission should be 

available? Validation in the laboratories – all required subsystems shall be included to be able to simulate the 

system as installed. 

Mr. Roach, California Division of Measurement Standards, stated that if the software package being evaluated 

supports platforms/subsystems from multiple manufacturers, testing should be done using at least two 

platforms/subsystems. Scale laboratories and scale manufacturers indicated that this is not usually done for scale 

evaluations. 

Since the NTEP Committee passed the related item at NCWM Annual Meeting, we will continue to work on this. 

Mr. Truex, NTEP Administrator, indicated that we can move in this direction, but felt that it was somewhat 

premature to develop this thoroughly now. At the point where the Sector has developed checklist requirements, then 

we could move to perhaps add a subsection to current NTEP applications for applicable software. Refer to 

D-31.6.1. It was also agreed that there seems to be no reason for limiting the scope of this item to software-only 

applications, and, hence, all software/software-based devices could benefit from an enhanced application process. 

Hence, the description of this agenda item was modified as shown in the marked up heading. 

Comments given at the meeting indicate that current practice does not require anything different for 

software/software based devices compared to any other type approval. It was also noted that for international 

applications, OIML D-31.6.5 states, “The approval applicant is responsible for the provision of all the required 

equipment and components.” This would likely also be the policy of NTEP. 

Since the checklist is still being tried out by some of the laboratories, the Sector is not quite ready to develop this 

fully. Some documentation that eventually might be required by applicants could include (from WELMEC doc. 7-2, 

Issue 4): 

 A description of the software functions that are metrologically significant, meaning of the data, etc. 

 A description of the accuracy of the measuring algorithms (e.g., price calculation and rounding algorithms). 

 A description of the user interface, menus, and dialogs. 

 A description of the method of sealing. 

 The software identification (version, revision, etc.) and how to view it. 

 An overview of the system hardware, for example topology block diagram, type of computer(s), type of 

network, etc, if not described in the operating manual. 
NTEP Committee 2014 Final Report 

Appendix E – 2013 NTEP Software Sector Summary 

NTEP - E17 

 An overview of the security aspects of the operating system software (e.g. protection, user accounts, 

privileges, etc). 

 The operating manual. 

Conclusion: 

The Sector recommends including the above bulleted list as an introduction to the checklist as part of our 

recommendation to include the checklist from Agenda Item 3 in NCWM Publication 14. As a description of the 

accuracy of the measuring algorithms, simply declaring the type and class being aimed for may be sufficient. This 

list should reflect the needs of the labs for an evaluation. The bulleted list and the paragraph before it should be 

brought to the labs for an initial review and their input.

6. Training of Field Inspectors 

Source: 

NTETC Software Sector 

Background: 

During discussions at the 2009 NTETC Software Sector Meeting, the Sector concluded that a new agenda item 

should be initiated specific to the training of field inspectors in relation to evaluating/validating software-based 

devices. 

California has an Examination Procedure Outline (EPO) that begins to address this. Use California Handbook 112 

as a pattern template for how it could read. 

Items to be addressed: 

 Certificate of Conformance (CC) 

 Terminology (as related to software) beyond what is in NIST Handbook 44. 

 Reference materials/information sources 

 Safety 

System Verification Tests: 

NOTE: Item numbers 1 through 5 apply to both weighing and measuring devices. Numbers 6 and 7 are specific to 

weighing devices; while numbers 9 and 10 apply to measuring devices. 

1. Identification. The identification (ID) tag may be on the back room computer server and could be viewed 

on an identification screen on the computer monitor. The ID information may be displayed on a menu or 

identification screen. Though currently discouraged, some systems may be designed so the system must be 

shut down and reset to view the ID information. G-S.1. [1.10] 

1.1. Manufacturer. 

1.2. Model designation. 

2. Provisions for sealing. G-S.8. [1.10]; S.1.11 [2.20]; S.2.2 [3.30] 

2.1. Verify sealing category of device (refer to Certificate of Approval for that system). 

2.2. Verify compliance with certificate. 

3. Units of measure. 

3.1. A computer and printer interfaced to a digital indicator shall print all metrological values, intended to 

be the same, identically. G-S.5.2.2.(a); G-S.5.1 [1.10] 

3.2. The unit of measure, such as lb, kg, oz, gal, qts, liters, or whatever is used, must agree. 

4. Operational controls, indications and features (buttons and switches). Verify that application criteria and 

performance criteria are met (refer to Certificate of Approval). 

4.1. Any indication, operation, function, or condition must not be represented in a manner that interferes 

with the interpretation of the indicated or printed values. 

5. Indications and displays. 
NTEP Committee 2014 Final Report 

Appendix E – 2013 NTEP Software Sector Summary 

NTEP - E18 

5.1. Attempt to print a ticket. The recorded information must be accurate or the software must not process 

and print a ticket with erroneous data interpreted as a measured amount. 

Weighing Devices 

6. Motion detection. 

6.1. For railway track, livestock, and vehicle scales apply or remove a test load of at least 15d while 

simultaneously operating a print button, push-button tare or push-button zero. A good way to do this is to 

try to print a ticket while pulling the weight truck or another vehicle onto the scale. Recorded values shall 

not differ from the static display by more than 3d. Perform the test at 10 %, 50 % and 100 % of the 

maximum applied test load. S.2.5.1.(a) [2.20]; EPO NO. 2-3, 2.4 

6.2. For all other scales, apply or remove at least 5d. Printed weight values must agree with the static 

weight within 1d and must exactly agree with other indications. S.2.5.4.(b) [2.20]; EPO NO. 2-3, 2.4 

7. Behind zero indication. 

7.1 Apply a load in excess of the automatic zero setting mechanism (AZSM) and zero the scale. S.2.1.3. 

[2.20]; EPO NO. 2-3, 2.4, 2.5.2 

Example: On a vehicle scale have someone stand on the scale, then zero them off (AZSM is 3d). Remove 

the weight (person) and note the behind zero display (usually a minus weight value) or error condition. 

7.2. Attempt to print a ticket. With a behind zero condition, (manually or mechanically operated) a negative 

number must not be printed as a positive value. 

8. Over capacity. 

8.1. Manually enter a gross weight if permissible or apply a test load in excess of 105% of the scale’s 

capacity. S.1.7. [2.20]; S.1.12., UR.3.9. [2.20] 

8.2. Attempt to print a weight ticket. A system must not print a ticket if the manually entered weight or load 

exceeds 105 % of the scale capacity. 

Measuring Devices 

9. Motion detection. 

9.1. Initiate flow through the measuring element. Attempt to print a ticket while the product is flowing 

through the measuring chamber. The device must not print while the indication is not stable. S.2.4.1. (3.30) 

10. Over capacity. 

10.1. Attempt to print a ticket in excess of the indicated capacity. A system must not print a ticket if the 

device is manually or mechanically operated in excess of the indicated value. 

NOTE: Be aware of error codes on the indicator which may be interrupted as measured values. 

Mr. Jordan, California Division of Measurement Standards, is already doing something similar, and he may be able 

to assist. Mr. Roach, California Division of Measurement Standards, will talk to him to see whether they’re 

available. In addition, Mr. Parks, California Division of Measurement Standards, is based in Sacramento, 

California, and a potential resource. If the meeting is held in Sacramento next year, they may be able to attend. 

Mr. Truex, NTEP Administrator, pointed out that the PDC would also be a valuable resource on this subject. 

Mr. Pettinato, Co-Chair, will contact them. 

*NIST Handbook 112 – Examination Procedure Outline for Commercial Weighing and Measuring Devices.

Discussion:

The Sector would like to enlist field inspectors from a variety of states review California’s Handbook 112, 

especially the excerpt above, to see if they think it would be of use to them. We’ll obtain approval from California 

before we disseminate this documentation. 

The PDC is focused on training sessions at the moment, so it’s unsure how much time they’d have to review this 

currently. 

There is a NIST/NCWM initiative on training. Dr. Thompson is going to bring this to their attention. 
NTEP Committee 2014 Final Report 

Appendix E – 2013 NTEP Software Sector Summary 

NTEP - E19 

Aside from the general list of things to check, shown above, providing specific examples of scenarios they might 

encounter would likely be useful for field inspectors. A small working group, including Dr. Thompson, Mr. Ken 

Jones (or someone else from California), Mr. Jim Pettinato, (check with Mr. Don Onweiler) possibly other field 

inspectors, etc. would be best to generate some examples. 

A list of terms and acronyms could prove quite useful – not just to field inspectors, but perhaps even more so for 

type evaluators. The following is not really a list of definitions so much as various explanations of terms: 

 CRC: Cyclical Redundancy Check 

 Checksum 

 Embedded software 

 Firmware 

 Version/Revision/Software Identifier: One component of a software identifier might be analogous to a 

model number, another component might be a version/revision, and another component might be a 

checksum. To satisfy the identification requirement, at a minimum, you need an identifier analogous to the 

model and a version/revision. In a product that has multiple pieces of software, you might require multiple 

software identifiers. For purposes of this list, Version and Revision are used synonymously. 

 The difference between a serial number and a version/revision: Serial numbers are unique identifiers for a 

physical product. Identical copies of software can exist on multiple physical pieces of equipment, so serial 

numbers aren’t truly relevant to software. Instead, a version/revision number, tied to the software itself, is 

used to identify the differences between one set of software features and another. In summary, hardware 

needs a serial number, and software needs a version/revision number. 

 Directly linked: Physical marking of hardware with a software version is useless as the software can be 

updated, in which case the physical marking would no longer be accurate. The preferred case is that the 

software self-identifies (displays version number, etc.) continuously or on demand. If the software 

changes, the version must change. There is an exception for situations where the device itself has no means 

to identify the software to the outside world, such as lacking a printer and a display. 

 Hash: This is used for validation and verification that software and/or data is authentic and valid. A hash 

function is any algorithm or subroutine that maps large data sets of variable length to smaller data sets of a 

fixed length. Examples include CRC, checksum, LRC, etc. Hashes are used because there is a very low 

probability of two different data blocks having the same hash code. 

 Signature 

 Metrologically significant software: Software that calculates or affects features and/or measurements that 

are sealable. 

 Software separation: Software can be divided into metrologically significant and non-metrologically 

significant sections. If it is, only metrologically significant software must be controlled. If separation is 

not employed, then the entire software is considered metrologically significant. “Controlled” implies that a 

separate software identifier for the metrologically significant software is used. 

 Software update 

 Sealable parameters: Reference Publication 14 typical features or parameters to be sealed. Note that the 

download of software is recommended to be considered a sealable parameter. 

 User interface: An interface forming the part of the instrument or measuring system that enables 

information to be passed between a human user and the measuring instrument or its hardware or software 

parts, such as, switch, keyboard, mouse, display, monitor, printer, and touch-screen. 

 Communications interface: An electronic, optical, radio, removable storage media, or other technical 

interface that enables information to be automatically passed between parts of measuring instruments, subassemblies, or external devices. 
NTEP Committee 2014 Final Report 

Appendix E – 2013 NTEP Software Sector Summary 

NTEP - E20 

 Reset/reboot 

 Non-volatile memory 

 Flash 

 Encryption 

 Authentication: Affirmation that the source of the software or data was genuine and recognized. This can 

be done either via an authorized agent or via specific software techniques. Authentication is employed in 

order to prevent loading of malicious software into devices. 

 Third-party software: Software that is loaded into the weighing or measuring system that was not provided 

by the original manufacturer. 

 Program 

 Subroutine 

We will flesh out this list, adding some brief definitions and/or examples. It will then be circulated amongst this 

group for review, and for any additional terms that are identified as being potentially useful. 

Mr. Doug Bliss suggested developing educational presentations on relatively small software subjects, for 

presentation at the conferences, to provide training. We’ll check into availability of time slots. January or next July 

are probably the earliest opportunities. Potential topics might include: 

 General “software isn’t scary” 

 Background on why the software sector exists and what we’re trying to accomplish 

 Something to tie into the training of field inspectors on software 

 Software identification 

 Teaching inspectors how to read a certificate, with an eye toward information pertaining to software 

Conclusion: 

The Sector sees value in assisting in the training of field inspectors on several fronts as indicated by the discussion at 

this year’s meeting. Several initiatives will be floated amongst the NCWM community and the Sector will focus on 

those that seem to have the most interest/benefit to the Conference. 

NEW ITEMS 

7. Next Meeting 

Background: 

The Sector is on a yearly schedule for NTETC Software Sector Meetings. Mr. Truex, NTEP Administrator, will 

determine when the next meeting is possible. This year was California’s turn in the rotation to host the meeting, but 

due to the uncertainly of New York’s status as potential host, the meeting ended up being back in Ohio. Hence, 

New York and California again are possible locations for the 2014 meeting. 

Albany, New York, and California remain under consideration, with New York being the first choice, preferably as 

late as possible in March. 
NTEP Committee 2014 Final Report 

Appendix E – 2013 NTEP Software Sector Summary 

NTEP - E21 

8. 2013 NCWM Interim Meeting Report 

There was one item on the NCWM S&T Committee Agenda for the 2012 NCWM Interim Meeting related to work 

done by the NTETC Software Sector. 2012 NCWM Publication 15, S&T Item 360-2 relates to the 2012 NTETC 

Software Sector Agenda Item 1: Marking Requirements. 

The Sector was informed of the S&T Committee decision to continue Item 360-2 as a Developing item. 

9. 2013 International Report 

Dr. Ambler Thompson, NIST, Office of Weights and Measures (OWM), will provide a synopsis of international 

activity that relates to the work of the Sector. Software Sector Co-Chair, Mr. Jim Pettinato, will summarize the 

discussion that took place at the European Cooperation in Legal Metrology (WELMEC) WG7 meeting in 

December 2011. 

Highlights of interest to the NTETC Software Sector: 

 New WELMEC 7.2 draft document circulated for comment by WG7 

 R-117 working group 

10. 360-7 D Appendix D – Definitions: Remote Configuration Capability 

Source: 

NTETC Grain Analyzer Sector (2013) 

Purpose: 

Expand the scope of definition to cover instances where the “other device” as noted in the current definition, may be 

necessary to the operation of the weighing or measuring device or which may be considered a permanent part of that 

device. 

Item Under Consideration: 

This item is under development. Comments and inquiries may be directed to NIST Office of Weights and 

Measures. 

A proposal to modify the definition for “remote configuration capability” as follows is under consideration: 

remote configuration capability. – The ability to adjust a weighing or measuring device or change its 

sealable parameters from or through some other device that is not may or may not itself be necessary to 

the operation of the weighing or measuring device or is not may or may not be a permanent part of that 

device.[2.20, 2.21, 2.24, 3.30, 3.37, 5.56.(a)] 

(Added 1993, Amended 20XX) 

Background/Discussion: 

Removable digital storage devices can be used in GMMs as either data transfer devices that are not necessary to the 

operation of the GMM or as data storage devices which are necessary to the operation of the GMM. If removal data 

storage devices are necessary to the operation of the device, they are not covered by the current definition of remote 

configuration capability. 

A USB flash drive is most likely to be used as a data transfer device. In a typical data transfer application, the USB 

flash drive is first connected to a computer with access to the GMM manufacturer’s web site to download the latest 

grain calibrations that are then stored in the USB flash drive. The USB flash drive is removed from the computer 

and plugged into a USB port on the GMM. The GMM is put into remote configuration mode to copy the new grain 
NTEP Committee 2014 Final Report 

Appendix E – 2013 NTEP Software Sector Summary 

NTEP - E22 

calibration data into the GMM’s internal memory. When the GMM has been returned to normal operating 

(measuring) mode, the USB flash drive can be removed from the GMM. 

Although a Secure Digital (SD) memory card could also be used as a data transfer device, it is more likely to be used 

as a data storage device. In a typical “data storage device” application, the SD memory card stores the grain 

calibrations used on the GMM. The SD memory card must be plugged into an SD memory card connector on a 

GMM circuit card for the GMM to operate in measuring mode. To install new grain calibrations the GMM must be 

turned “off” or put into a mode in which the SD memory card can be safely removed. The SD memory card can 

either be replaced with an SD memory card that has been programmed with the new grain calibrations or the original 

SD memory card can be re-programmed with the new grain calibrations in much the same way as that described in 

the preceding paragraph to copy new grain calibrations into a USB flash drive. In either case, the SD memory card 

containing the new calibrations must be installed in the GMM for the GMM to operate in measuring mode. In that 

regard, the SD memory card (although removable) can be considered a permanent part of the GMM in that the 

GMM cannot operate without it. 

Note: In the above example SD memory card could be any removable flash memory card such as the Secure Digital 

Standard-Capacity, the Secure Digital High-Capacity, the Secure Digital Extended-Capacity, and the Secure Digital 

Input/Output, which combines input/output functions with data storage. These come in three form factors: the 

original size, the mini size, and the micro size. A Memory Stick is a removable flash memory card format launched 

by Sony in 1998, and is also used in general to describe the whole family of Memory Sticks. In addition to the 

original Memory Stick, this family includes the Memory Stick PRO, the Memory Stick Duo, the Memory Stick PRO 

Duo, the Memory Stick Micro, and the Memory Stick PRO-HG. 

At its 2011 Grain Analyzer Sector Meeting the Sector agreed by consensus that the following changes to Table 

S.2.5. of §5.56.(a) of NIST Handbook 44 should be forwarded to the S&T Committee for consideration: 

 Add a note to Table S.2.5. to recognize the expanded scope of remote capability. 

 Delete “remotely” from the second paragraph of Category 3 requirements that begins, “When 

accessedremotely ...” to make it clear that the requirements of Category 3 apply whether accessed 

manually using the keyboard or accessed by remote means. 

 Add the modified second paragraph of Category 3 requirements to Categories 3a and 3b to make it 

clear that these requirements apply to all the subcategories of Category 3. 

After additional review of this item, the NIST, OWM recommended that the changes to Table S.2.5. approved by the 

Sector in 2011 be separated into two independent proposals: one dealing with the changes to Category 3 and its 

subcategories and one recommending a modification of the definition of Remote Configuration Capability appearing 

in Appendix D of NIST Handbook 44 to recognize the expanded scope of remote capability, instead of adding a note 

to the bottom of Table S.2.5. to expanded the definition for remote configuration for grain moisture meters (as 

shown in this proposal). A change to the definition of remote configuration capability will apply to other device 

types. 

2012 Grain Analyzer Sector Meeting: The sector agreed by consensus to separate its original proposal into two 

separate proposals and that this proposal to change the definition of Remote Configuration Capability should be 

forwarded to the S&T to Committee for consideration. 

Item 5 of the NTETC, Grain Analyzer Sector August 2012 Meeting Summary covers this subject and will be 

available on NCWM Website, November 2012. 

2012 NCWM Annual Meeting: Ms. Juana Williams NIST, OWM supported the intent. She talked about this item in 

conjunction with Item 356-1: S.2.5. Categories of Device and Methods of Sealing. This is such a complex item 

affecting multiple other devices; therefore, the proposal requires further consideration. The language in the proposal 

to amend the definition of remote configuration capability is confusing. The Committee believes the current 

definition already allows the use of remote configuration devices and allows the flexibility desired. The 
NTEP Committee 2014 Final Report 

Appendix E – 2013 NTEP Software Sector Summary 

NTEP - E23 

ramifications of changing the definition could affect other devices in HB 44. WWMA did not forward this item to 

NCWM. 

2012 SWMA Annual Meeting: There were no comments. After reviewing the proposal and considering the 

potential impact on other device types, the Committee recommended this as a Developing Item. The Committee 

asks that the Sector continue to obtain input on the definition and the impact the changes would have on other device 

types. SWMA forwarded the item to NCWM, recommending it as a Developing Item and assigning its development 

to the Grain Analyzer Sector. 

During its Open Hearings at the 2013 NCWM Interim Meeting, the Committee heard comments from Ms. Juana 

Williams (NIST OWM). OWM suggests the Committee consider this item as a Developing Item to allow other 

Sectors to discuss how a change to the definition may affect other device types of similar design and to consider 

changes if needed. OWM recognizes that the current definition for “remote configuration capability” may not 

address those grain moisture meters (GMMs) which can only be operated with a removable data storage device, 

containing, among other things, the grain calibrations intended for use with the GMM, inserted in the device (as was 

described by the Grain Analyzer Sector). As such, OWM notes that current sealing requirements were developed at 

a time when such technology likely didn’t exist, nor could be envisioned, and are based on the current definition of 

remote configuration capability. Because the current definition was never intended to apply to this “next 

generation” technology, OWM suggests that those charged with further development of this item may wish to revisit 

the five philosophies of sealing and consider whether a new paragraph, completely separate from current sealing 

requirements, might be appropriate and a better option, than the one currently proposed. The five philosophies of 

sealing are included in the 1992 Report of the 77th National Conference on Weights and Measures (Report of the 

Specifications and Tolerances Committee). Another option, preferred over the changes currently proposed, would 

be to add a separate statement to the current definition of “remote configuration capability” to address removable 

storage devices. For example, the following sentence might be considered as an addition to the current definition for 

“remote configuration capability:” 

Devices which are programmed using removable media (such as SD cards, flash drives, etc.) that 

may or may not be required to remain with the device during normal operation are also considered 

to be remotely configured devices. 

The Committee also heard comments from Mr. Dmitri Karimov (LC), speaking on behalf of the MMA, who made 

two points: (1) Flow computers may already have these capabilities, thus it may be more appropriate to consider 

adding requirements to the General Code so that the requirements will be uniformly applied to all device types; and 

(2) the Committee should look ahead and consider other capabilities that may or already have emerged such as 

wireless communication and configuration. 

The Committee acknowledged the comments indicating that the current definition of “remote configuration 

capability” was developed at a time when certain technologies, such as blue tooth, SD storage devices, flash drives, 

etc., didn’t exist. The Committee recognized it may be difficult to modify the existing definition and associated 

requirements to be flexible enough to address emerging and future technologies without having a significant (and 

possibly detrimental impact) on existing devices. Consequently, rather than modifying the current definition, the 

Committee concluded that a better approach might be to develop an entirely separate set of security requirements 

that would apply to emerging technologies. The Committee believes additional work is needed to develop proposed 

definition(s) and associated requirements and decided to designate the item as Developmental. The Committee 

requests other Sectors review the Grain Sector’s proposed modification to the definition as well as OWM’s 

suggestions and provide input. 

Discussion: 

Mr. Jim Pettinato and Mr. Doug Bliss suggested this alternative, possibly with the addition of some examples: 
NTEP Committee 2014 Final Report 

Appendix E – 2013 NTEP Software Sector Summary 

NTEP - E24 

remote configuration capability. – The ability to adjust a weighing or measuring device or change its 

sealable parameters from or through some other device that is not may or may not itself be necessary to 

the operation of the weighing or measuring device or is not may or may not be a permanent part of 

that device.[2.20, 2.21, 2.24, 3.30, 3.37, 5.56.(a)] 

(Added 1993, Amended 20XX) 

This proposal is technology-agnostic and addresses the concern that any revision of the definition would be tied to 

existing technology. 

The Sector is curious as to how updates to the calibration parameters via either USB or SD cards are being handled 

to date. For example, when replacing an SD card, are the parameter changes being recorded in an audit trail? 

Conclusion: 

We will forward this comment to the S&T Committee and the Grain Analyzer Sector. 
NTEP Committee 2014 Final Report 

Appendix E – 2013 NTEP Software Sector Summary 

Sub-Appendix A – List of Acceptable Menu Text/Icons for Identification of Certificate Number 

NTEP – E / A1 

Appendix A 

List of Acceptable Menu Text/Icons for Identification of Certificate 

Number 

Table 1 - Software Sector Proposed Menu Text /Icons 

Permitted Menu Text 

examples 

Permitted 

Icon shape 

examples 

Essential characteristics 

Information 

Info 

 Top level menu text or icon 

 Icon text is a lower case “i” with block serifs 

 Text color may be light or dark but must contrast 

with the background color 

 Icon may have a circular border 

 Activation of this menu text/icon may invoke a 

second level menu text/icon that recalls metrology 

information. 

Help 

? 

 Top level menu text or icon 

 Icon text is a question mark 

 Text color may be light or dark but must contrast 

with the background color 

 Icon may have a circular border 

 Activation of this menu text/icon may invoke a 

second level menu text/icon that recalls metrology 

information. 

Metrology 

Metrological Information 

M Top or second level menu text or icon 

 Icon text is an upper case “M” 

 Text color may be light or dark but must contrast 

with the background color 

 Icon may have a circular, rectangular, or rounded 

rectangle border. 

 If present, the activation of this menu text/icon must 

recall at a minimum the NTEP CC number. 

NTEP Data 

N.T.E.P. Certificate 

This one is debatable – what if the certificate is revoked? 

Does NTEP grant holders of CCs the right to display the 

logo on the device, or just in documentation? 

Weights & Measures Info W&M 

W/M 

?

?

?

M
NTEP Committee 2014 Final Report 

Appendix E – 2013 NTEP Software Sector Summary 

Sub-Appendix A – List of Acceptable Menu Text/Icons for Identification of Certificate Number 

NTEP – E / A2