Standard Guide for Computerized Exchange of Corrosion Data for Metals

SIGNIFICANCE AND USE
4.1 This guide establishes a formalism for transferring corrosion test data between computer systems in different laboratories. It will be used by standards developers to specify the format of files containing test results.  
4.2 This guide defines a generic approach to structuring data files. It will be used by software developers to create programs which read and write these files.  
4.3 Each standard test procedure will define a unique data file derived from this guide. Each time a standard test is performed, the results can be summarized in a data file specific to that test.  
4.4 Some experimental information will be global, that is, common to several standards, and will be contained in Guide G107 and other global data dictionaries. Other information will be local, that is, unique to a given standard, and will be defined in that standard.
SCOPE
1.1 This guide covers the techniques used to encode corrosion of metals test results for exchange between computer systems.  
1.2 Guidelines are given for creating a data exchange appendix for each ASTM corrosion of metals standard.  
1.3 Instructions are given for creating data translation software from the contents of the data exchange appendix.

General Information

Status
Historical
Publication Date
30-Apr-2013
Current Stage
Ref Project

Relations

Buy Standard

Guide
ASTM G135-95(2013) - Standard Guide for Computerized Exchange of Corrosion Data for Metals
English language
10 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)


NOTICE: This standard has either been superseded and replaced by a new version or withdrawn.
Contact ASTM International (www.astm.org) for the latest information
Designation: G135 − 95 (Reapproved 2013)
Standard Guide for
Computerized Exchange of Corrosion Data for Metals
This standard is issued under the fixed designation G135; the number immediately following the designation indicates the year of
original adoption or, in the case of revision, the year of last revision. A number in parentheses indicates the year of last reapproval. A
superscript epsilon (´) indicates an editorial change since the last revision or reapproval.
1. Scope 3.1.7 translator—a computer routine which writes or reads
data files.
1.1 This guide covers the techniques used to encode corro-
sion of metals test results for exchange between computer
4. Significance and Use
systems.
4.1 This guide establishes a formalism for transferring
1.2 Guidelines are given for creating a data exchange
corrosion test data between computer systems in different
appendix for each ASTM corrosion of metals standard.
laboratories. It will be used by standards developers to specify
1.3 Instructions are given for creating data translation soft-
the format of files containing test results.
ware from the contents of the data exchange appendix.
4.2 Thisguidedefinesagenericapproachtostructuringdata
2. Referenced Documents
files. It will be used by software developers to create programs
which read and write these files.
2.1 ASTM Standards:
G106 Practice for Verification of Algorithm and Equipment
4.3 Each standard test procedure will define a unique data
for Electrochemical Impedance Measurements
file derived from this guide. Each time a standard test is
G107 Guide for Formats for Collection and Compilation of
performed, the results can be summarized in a data file specific
Corrosion Data for Metals for Computerized Database
to that test.
Input
4.4 Some experimental information will be global, that is,
2.2 ANSI Standards:
common to several standards, and will be contained in Guide
ANSI/ISO 9899 1990 [1992] Programming Language C
G107andotherglobaldatadictionaries.Otherinformationwill
ANSI X3.4-1986 Coded Character Set 7 Bit ASCII
be local, that is, unique to a given standard, and will be defined
3. Terminology in that standard.
3.1 Definitions:
5. Guide for Standards Authors
3.1.1 datatype—a group of rules specifying the format of an
object.
5.1 Local and Global Data:
3.1.2 global data—information shared among several stan-
5.1.1 Some information may be used across several corro-
dards.
sion standards, that is, global. Global data is defined in Guide
G107 and other global standards.
3.1.3 local data—information specific to a certain standard.
5.1.2 Some information may be local to a particular corro-
3.1.4 semantics—information meaning.
sion standard. Local data is defined in the standard’s data
3.1.5 syntax—information format.
exchange appendix.
3.1.6 tagged object—a named block of information.
5.2 Data File:
5.2.1 Eachtestwillgenerateasingletestdatafile.Filename
This guide is under the jurisdiction ofASTM Committee G01 on Corrosion of
formats are not specified.
Metals and is the direct responsibility of Subcommittee G01.05 on Laboratory
5.2.2 The data file is arranged as a set of named or tagged
Corrosion Tests.
CurrenteditionapprovedMay1,2013.PublishedJuly2013.Originallyapproved
objects. Each time a standard test is performed a set of objects
in 1995. Last previous edition approved in 2007 as G135–95(2007). DOI:
is obtained. The data file can be thought of as a permanent
10.1520/G0135-95R13.
repository for this set of objects.
For referenced ASTM standards, visit the ASTM website, www.astm.org, or
contact ASTM Customer Service at service@astm.org. For Annual Book of ASTM
5.2.3 Each tagged object will take two or more lines in the
Standards volume information, refer to the standard’s Document Summary page on
data file. Lines are strings of ASCII (ANSI X3.4-1986)
the ASTM website.
characters terminated with a carriage return/linefeed character
Available fromAmerican National Standards Institute (ANSI), 25 W. 43rd St.,
4th Floor, New York, NY 10036, http://www.ansi.org. pair or a single linefeed character.
Copyright © ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959. United States
G135 − 95 (2013)
5.2.4 Lines are further subdivided into tab delimited ASCII
fields that are particularly suitable for manipulation by spread-
sheet and scientific charting programs. For example, Fig. 1
shows how a section of a data file would show up on printed
output.
FIG. 2 The Elements of a Tagged Object
5.3 Tagged Object:
5.3.1 Atagged object is a repository for an individual block
of information. It may be a simple piece of data, the test date
for example, or it may be complex, such as a current/voltage/ (a) String (STRING)—Strings contain purely character in-
time curve. A tagged object contains three subordinate areas: formation. Strings may be further encoded depending on the
(1) the tag, (2) the datatype, and (3 ) the actual data. The tag semantic description of the object.
(b) Quantity (QUANT)—Quantities represent numeric val-
and datatype are the first two fields of the first line while the
actual data is contained in subsequent lines. Data lines are ues along with their units. Units may be further encoded
depending on the semantic description of the object.
always indented one tab space. This is illustrated in Fig. 2.
5.3.2 Tag: (c) Date (DATE)—Dates are simple day specifiers.
5.3.2.1 The object’s tag is a simple string that uniquely (d) Time (TIME)—Times are simple time of day specifiers.
identifies it among other objects in a tagged object set. (e) Category Set (SET)—Category sets are used to repre-
5.3.2.2 When implementing a translator for a given sent choices. The actual meaning of each value is given in the
standard, the implementation is free to define other tagged semantic description of the object.
object names so long as they don’t clash with those defined in (f) Tabular (TABLE)—Tables are used to hold arrays of
the standard. It is suggested that additional names be prefixed records. The datatype, units, and name of each column is also
with some unlikely and unique combination of alphanumeric encoded.
characters so that name conflicts do not arise in future versions 5.3.3.3 Aparticularimplementationofatestisfreetodefine
of the standard. For example; NewTest_Apex Potential. local datatypes as long as they don’t clash with those defined
5.3.2.3 Tags are made up of one or more character strings in global standards. These local datatypes are defined in the
separated by periods. The first character in each string must be standard’s data exchange appendix.
alphabetic (including the underscore). Subsequent characters 5.3.3.4 The datatype has a unique identifier made up of a
may be alphanumeric. standard number and a name separated by a period; for
5.3.2.4 Periods should only be used to associate different example, G107.SET. Each time an object is recorded in the
objects together. For example, Matl.Class, Matl.SubClass, data file, the datatype identifier is recorded with the object.
Matl.TradeName, are all aspects of Material. In future speci- That identifier specifies to the translator (either computer or
fications it is suggested that this be done using complex, human) what data format to use in reading the data from or
writing the data to the file.
multifield datatypes.
5.3.2.5 Periodsshouldnotbeusedtoseparatemultipleword 5.3.3.5 In cases where the reading translator is unable to
individual concepts. Instead use capitalization or underscore. find a datatype in its internal table, that object will be marked
For example; ControlMode or Control_Mode. as untranslated. The translator is free to take the appropriate
5.3.2.6 Tags are case insensitive although mixed case is action depending on the importance of the object.
suggested for readability. 5.3.3.6 It is important to note that the datatype doesn’t
5.3.3 Datatype: completelyspecifythemeaningofthedata,onlyitsformat.For
5.3.3.1 Each object has a datatype which specifies the example, a value of one for the tag “Surface.Condition” has a
format of the object’s data. very different meaning than the value of one for the tag
5.3.3.2 Global datatypes are defined in a global data ex- “Potentiostat.ControlMode” even though they are both of type
change standard such as Guide G107 and are repeated here for G107.SET. Those meanings are construed from the tag.
reference, as follows: 5.3.4 Data:
FIG. 1 Data File Sample
G135 − 95 (2013)
form text describing the object. Constraints, defaults, or other specifica-
5.3.4.1 The object’s data is arranged in a format defined by
tions may show up here.
the datatype. Data starts in the second line of the data object.
(e) Datatype (Column 5)—The type gives the datatype of the object.
There may be multiple lines and multiple fields associated with
The data types may be global types defined in Guide G107, or they may
a data object. Each data line is indented by one tab space to
be local to the standard being written.
distinguish it from the tag/datatype lines.
(f) Category Set/Units/Column Information (Column 6)—This column
varies depending on the datatype. If the type is a SET, Column 6 contains
5.4 Data Exchange Appendix:
the allowed values and meanings. If the type is a QUANT, Column 6
5.4.1 Standard tests that use this guide will contain a data
contains suggested units. If the type is a TABLE, Column 6 contains units
exchange appendix. This appendix contains the data and or allowed values as required by the datatype of each column.
format information required to define test data files. For an
5.4.4 The last required section of the data exchange appen-
example see Appendix X1.
dix is a sample data file. This should show a file as actually
5.4.1.1 Thedataexchangeappendixshouldhavethreeparts,
printed although data may be omitted for the sake of space.
the local datatype definitions section, the object definition
table, and a sample data file.
6. Guide for File Translator Programmers
5.4.2 The local datatype definitions section gives a descrip-
6.1 The following section is intended for programmers who
tionofandformalsyntaxforeachlocaldatatype.Thisgivesthe
are writing data exchange translators. A translator is a portion
rulesoftranslationtoprogrammerswhoarecreatingtranslators
of a program which reads or writes a data file. Production rules
for the standard.
are shown in bold-face Courier font.
5.4.2.1 The rules should be written using the formal lan-
guage described in Section 7. The translation rules for several 6.1.1 Character Set—ThedataisstoredinanASCIItextfile
data types are given in Section 6. The QUANT type is which can be directly printed using most printers and manipu-
lated using most text editors (see Fig. 4).
reproduced in Fig. 3 as an example:
5.4.3 The object definition table is a tabular listing of all the
6.1.2 File—The data file is arranged as a sequence of tagged
objects in the file. For example, consider Table 1. There are
objects.
four objects in this table: Standard, Date, ControlMode, and
File : = TaggedObject [1 . .*]
Spectrum. In an actual standard there may be many more.
6.1.3 Tagged Object—Atagged object starts with its tag line
5.4.3.1 Each row of the table defines a data object. These
and includes all the information up to the next tag. Any other
objects may be copied from global standards such as Guide
lines associated with the object must be indented one tab
G107 or may be locally defined. An object definition should
character. Each line is terminated with a line feed or carriage
not refer to another standard test since a revision of that test
return/line feed pair.
may change the object definition without warning.
TaggedObject : = TagLine DataBlock
5.4.3.2 Column Definitions (as illustrated in Table 1):
6.1.3.1 Tag Line—The first line of a tagged object is called
NOTE 1—Columns 1, 2, and 3 are required for global objects. Columns
the Tag Line. It contains the tag or name of the object and the
1 to 6 are required for local objects.
(a) Reference Number (Column 1)—The reference number is a unique format specifier.
numberreferringbacktothestandardandparagraphwherethedataobject
TagLine : = TagField FormatField {CommentField} NewLine
is defined. This number is made up of a Standard ID and a paragraph
number separated by a period(.). 6.1.3.2 Tag—Atagmuststartwithanalphabeticcharacteror
(b) Tag/ColumnTag(Column2)—Thiscolumncontainsthedatatag.If
underscore ( ___ ). Thereafter numeric characters can be used
the data object is tabular, this column will also contain sub-tags or
as well as alphabetic and underscore. Tags may not contain
headings for each column of the object.
spaces. The only other punctuation allowed is a period (.)
(c) Required (Column 3)—This column indicates whether a particular
character.Any character following a period must be alphabetic
object is required or can be safely omitted from the data file.
(d) Description (Column 4)—The description column contains free or underscore. Tags are not case sensitive.
FIG. 3 Translation Rules for the Quant Data Object
G135 − 95 (2013)
TABLE 1 Object Definitions
Reference Number/ Category Set/Suggested Units/
Tag/Column Tag Required Description/Column Description Type/Column Type
Column Number Column Information
G107.5.1.4.1 Standard Yes Standard test specification STRING
G107.5.1.4.3 Date Yes date test started DATE
G106.X2.1 ControlMode Yes Circuit configuration SET Allowed Values
1. Potentiostat
2. Galvanostat
3. ZRA
4. V applied/No feedback
5. I applied/No feedback
6. Other
G106.X2.2 Spectrum Yes Corrected frequency spectrum TABLE
Column 1 Frequency Frequency QUANT Hz
Column 2 Signal Applied Signal QUANT V, A
Column 3 ZReal Z real QUANT ohm
Column 4 ZImag Z imaginary QUANT ohm
Column 5 StdDev Standard Deviation QUANT none
FIG. 4 Definition of the Character Set
TagField : = Tag Tab FormatField : = {Organization Period} Standard Period Identifier Tab
Tag : = Identifier (Period Identifier) [0 . .*]
6.1.3.4 Data Lines—Any lines following the tag line up to
Identifier : = AlphabeticChar AlphanumericChar [0 . .*]
the next tag line are data lines associated with the tagged
6.1.3.3 Format—The second field in the Tag Line is a
object.Aspreviouslystated,datalinesmustbeginwithatabso
format specifier, either by paragraph reference; for example,
that they may be distinguished from tag lines. The data lines
Guide G107.7.1.4.1, or by shorthand name; for example,
are subdivided into tab delimited fields, that is, each data field
STRING. The format specifier specifies how the rest of the
tagged object is to be translated. is followed by a tab.
G135 − 95 (2013)
DataBlock : = DataLine [0 . .*] DateDataBlock : = DateDataLine
DataLine : = Tab
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.