Standard Guide for Computerized Exchange of Corrosion Data for Metals

SIGNIFICANCE AND USE
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.
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.
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.
Some experimental information will be global, that is, common to several standards, and will be contained in Guide G 107 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-2007
Current Stage
Ref Project

Relations

Buy Standard

Guide
ASTM G135-95(2007) - 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 2007)
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.
Current edition approved May 1, 2007. Published May 2007. Originally
objects. Each time a standard test is performed a set of objects
approved in 1995. Last previous edition approved in 2001 as G135–95(2001). DOI:
is obtained. The data file can be thought of as a permanent
10.1520/G0135-95R07.
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 (2007)
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.
and datatype are the first two fields of the first line while the (b) Quantity (QUANT)—Quantities represent numeric val-
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 stan- sent choices. The actual meaning of each value is given in the
dard, the implementation is free to define other tagged object semantic description of the object.
names so long as they don’t clash with those defined in the (f) Tabular (TABLE)—Tables are used to hold arrays of
standard. It is suggested that additional names be prefixed with records. The datatype, units, and name of each column is also
some unlikely and unique combination of alphanumeric char- encoded.
acters so that name conflicts do not arise in future versions of 5.3.3.3 Aparticularimplementationofatestisfreetodefine
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
multifield datatypes. writing the data to the file.
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 (2007)
tions may show up here.
5.3.4.1 The object’s data is arranged in a format defined by
(e) Datatype (Column 5)—The type gives the datatype of the object.
the datatype. Data starts in the second line of the data object.
The data types may be global types defined in Guide G107, or they may
There may be multiple lines and multiple fields associated with
be local to the standard being written.
a data object. Each data line is indented by one tab space to
(f) Category Set/Units/Column Information (Column 6)—This column
distinguish it from the tag/datatype lines.
varies depending on the datatype. If the type is a SET, Column 6 contains
the allowed values and meanings. If the type is a QUANT, Column 6
5.4 Data Exchange Appendix:
contains suggested units. If the type is a TABLE, Column 6 contains units
5.4.1 Standard tests that use this guide will contain a data
or allowed values as required by the datatype of each column.
exchange appendix. This appendix contains the data and
5.4.4 The last required section of the data exchange appen-
format information required to define test data files. For an
dix is a sample data file. This should show a file as actually
example see Appendix X1.
printed although data may be omitted for the sake of space.
5.4.1.1 Thedataexchangeappendixshouldhavethreeparts,
6. Guide for File Translator Programmers
the local datatype definitions section, the object definition
table, and a sample data file.
6.1 The following section is intended for programmers who
5.4.2 The local datatype definitions section gives a descrip-
are writing data exchange translators. A translator is a portion
tionofandformalsyntaxforeachlocaldatatype.Thisgivesthe
of a program which reads or writes a data file. Production rules
rulesoftranslationtoprogrammerswhoarecreatingtranslators
are shown in bold-face Courier font.
for the standard.
6.1.1 Character Set—ThedataisstoredinanASCIItextfile
5.4.2.1 The rules should be written using the formal lan-
which can be directly printed using most printers and manipu-
guage described in Section 7. The translation rules for several
lated using most text editors (see Fig. 4).
data types are given in Section 6. The QUANT type is
6.1.2 File—Thedatafileisarrangedasasequenceoftagged
reproduced in Fig. 3 as an example:
objects.
5.4.3 The object definition table is a tabular listing of all the
File : = TaggedObject [1 . .*]
objects in the file. For example, consider Table 1. There are
6.1.3 Tagged Object—Atagged object starts with its tag line
four objects in this table: Standard, Date, ControlMode, and
and includes all the information up to the next tag. Any other
Spectrum. In an actual standard there may be many more.
lines associated with the object must be indented one tab
5.4.3.1 Each row of the table defines a data object. These
character. Each line is terminated with a line feed or carriage
objects may be copied from global standards such as Guide
return/line feed pair.
G107 or may be locally defined. An object definition should
TaggedObject : = TagLine DataBlock
not refer to another standard test since a revision of that test
may change the object definition without warning.
6.1.3.1 Tag Line—The first line of a tagged object is called
5.4.3.2 Column Definitions (as illustrated in Table 1): the Tag Line. It contains the tag or name of the object and the
format specifier.
NOTE 1—Columns 1, 2, and 3 are required for global objects. Columns
TagLine : = TagField FormatField {CommentField} NewLine
1 to 6 are required for local objects.
(a) Reference Number (Column 1)—The reference number is a unique
6.1.3.2 Tag—Atagmuststartwithanalphabeticcharacteror
numberreferringbacktothestandardandparagraphwherethedataobject
underscore ( ___ ). Thereafter numeric characters can be used
is defined. This number is made up of a Standard ID and a paragraph
as well as alphabetic and underscore. Tags may not contain
number separated by a period(.).
(b) Tag/ColumnTag(Column2)—Thiscolumncontainsthedatatag.If spaces. The only other punctuation allowed is a period (.)
the data object is tabular, this column will also contain sub-tags or
character.Any character following a period must be alphabetic
headings for each column of the object.
or underscore. Tags are not case sensitive.
(c) Required (Column 3)—This column indicates whether a particular
TagField : = Tag Tab
object is required or can be safely omitted from the data file.
Tag : = Identifier (Period Identifier) [0 . .*]
(d) Description (Column 4)—The description column contains free
Identifier : = AlphabeticChar AlphanumericChar [0 . .*]
form text describing the object. Constraints, defaults, or other specifica-
FIG. 3 Translation Rules for the Quant Data Object
G135 − 95 (2007)
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
6.1.3.3 Format—The second field in the Tag Line is a 6.1.3.4 Data Lines—Any lines following the tag line up to
format specifier, either by paragraph reference; for example,
the next tag line are data lines associated with the tagged
Guide G107.7.1.4.1, or by shorthand name; for example,
object.Aspreviouslystated,datalinesmustbeginwithatabso
STRING. The format specifier specifies how the rest of the
that they may be distinguished from tag lines. The data lines
tagged object is to be translated.
are subdivided into tab delimited fields, that is, each data field
FormatField : = {Organization Period} Standard Period Identifier Tab
is followed by a tab.
G135 − 95 (2007)
DataBlock : = DataLine [0 . .*] DateDataBlock : = DateDataLine
DataLine : = T
...

Questions, Comments and Discussion

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