Data Communications Committee (DCC)Electronic Test Report Transmission Model (ETRTM)

Section 1Development and maintenance of data dictionaries

1.1 The hard copy test report must be developed to describe the data content and layout of the form.

1.2 Each parameter listed in the test report shall have a unique field name assigned. If a field appears more than once in a test report only the first occurrence shall be listed in the data dictionary.

1.3 The sequence of the fields is the order from left to right, top to bottom as the items appear on the Test Report Forms.

1.4 A maximum of an eight character test type designation must be assigned to the data dictionary. This designation is constructed based on industry wide consensus

1.5 Field Names consist of eight characters, must start with a letter (A-Z) and shall only contain letters, numbers and the underscore character. Every effort should be made to reuse field names across test areas if appropriate.

1.6 Field names that contain Hxxx or Rxxx in the last four positions of the name are designated repeating fields. The xxx part of the Hxxx mnemonic is to be numeric based. For example 100, 250 or 001. The Description field for Hxxx shall contain @ XXX Hours for these fields. (see repeating fields)

1.7 Standard naming conventions shall be used for the following types of data:

Final Results _____FNLFinal Results repeating F___RxxxCorrected Measurements _____CORCorrection Factors _____CFAdjusted Results _____ADJSeverity Adjustment _____SA

New Oil Viscosity V(t)NEW where t = temperature in the units specified

Only use the maximum of one underscore in the field name

1.8 The Total Field Length shall be specified. For character data, this is the number of characters including imbedded spaces that the field can contain. The length of all numeric fields includes a space for a sign (+/-) and a space for a decimal point. For example, xxxx.xx is stated as 7.2 and the number may look like -357.25. Always specify a minimum of 2 to the left of the decimal point for N and Z fields (+0.) giving the smallest field specification for N and Z floating point to be 5.1 (+00.0) and 2.0 for integers (+0). The following algorithm shall be used to verify correct field lengths of N and Z fields:

If the decimal size is greater than zero then the difference of field length – decimal size must be 4 or greater.orIf the decimal size is equal to zero then the difference of field length – decimal size must be 2 or greater.

1.9 The data type must be specified using the following 1 letter designation:A = Alpha/Numeric Data with numeric field Length and decimal size specified. All allowable alpha characters must be specified in the description enclosed with square brackets.C = Character DataN = Numeric Data which may contain a NULL valueZ = Numeric Data which may not contain a NULL but should contain a numeric value which is greater than, less than or equal to zero.

1.10 The units of measure shall be specified using the unit abbreviations found in the test procedure.

1.11 A textual description of the data item based on its title used in the test report shall be included. This description shall be unique for each field specified in the data dictionary.

1.12 The following is the Core Field Names that should be included in all Data Dictionaries:

F D DField Name L S T Unit Of Measure Description VERSION 8 0 C CCYYMMDD Version of the DictionaryTSTSPON1 40 0 C Conducted for, Line 1TSTSPON2 40 0 C Conducted for, Line 2ALTCODE1 15 0 C Alternate Oil Code 1ALTCODE2 15 0 C Alternate Oil Code 2ALTCODE3 15 0 C Alternate Oil Code 3SAEVISC 7 0 C SAE Viscosity GradeLABOCODE 20 0 C Laboratory Internal Oil CodeDTSTRT 8 0 C CCYYMMDD Starting DateSTRTTIME 5 0 C HH:MM Starting TimeDTCOMP 8 0 C CCYYMMDD Completed DateEOTTIME 5 0 C HH:MM End of Test TimeTESTLEN 5 0 Z HOURS Test LengthSUBLAB 40 0 C Submitted By: Testing LabSUBSIGIM 70 0 C Submitted By: Signature ImageSUBNAME 40 0 C Submitted By: NameSUBTITLE 40 0 C Submitted By: TitleOCOMRxxx 70 0 C Additional Comments

If the previous Reference Test information is required to be transmitted with the Non-Reference Test, fields must be created to send both sets of information. The Reference fields shall start with an ‘R’. i.e. DTSTRT for Non-Reference Starting Date and RDTSTRT for Reference Starting Date.

1.13 The test report may contain forms which contain graphs. A data dictionary which defines the data points which are needed to reproduce the graphs shall be designated as a Graph Data Dictionary.

1.13.1 The header (HDR) dictionary requires an additional field definition when used in conjunction with Graph Data Dictionaries which shall be defined as:

F D DField Name L S T Unit Of Measure Description INFOTYPE 6 0 C REPORT,GRAPH Information type

1.13.2 The following reserved names shall be included in all Graph Data Dictionaries:

F D DField Name L S T Unit Of Measure Description VERSION 8 0 C CCYYMMDD Version of DictionaryUNITS 15 0 C Units of measureSAMPLES 10 0 C Number of samplesSEQUENCE 5 1 N Sequence number

1.13.3 Each data point parameter for a set of graphs shall be defined as required.

1.14 Once a dictionary is in production, if a field is removed, it shall not be re-used in any future release of that dictionary.

1.15 When measurements are to be reported at specific intervals it is recommend that a repeating field be specified to report the actual interval of the measurement. (see Repeating Fields section)

1.16 If the units of a field change and no conversion is possible, a new name must be created.

1.17 If calculations surrounding a field name or the sub-components of that data change, naming of this field is to be reviewed.

1.18 When multiple statistical summaries are applied to multiple data sets of the same specific quantity, field names should be constructed of three parts.

1) A one character prefix used in any type of statistical summary such as A (average), I (minimum), X (maximum).

2) Up to 6 characters should be used to specify the parameter, such as RPM or Power.3) A one character suffix used to indicate the data set, such as 1 for stage 1.

Example: APOWER1, IPOWER1Note, that the implementation of this convention applies to a new beta release only.

Section 2Flat File Transmission Format

2.1 The format, referred to as the DCC Flat File Format, is to be used to send and receive the data dictionary described test report data.

2.2 All field names with their corresponding data found in the data dictionary for the particular test being transmitted shall be included in the flat file if they either contain data or are blank. This requirement enables the receiver of the data to verify that the entire report was received without any transmission errors. The only exceptions are (a) for an aborted test where only the information needed to identify the test must be included and (b) for a transmission of preliminary data.

2.3 Field Names shall start in column 1.

2.4 Data fields shall start in column 10 and end in column 80.

2.5 Data items do not have to be justified within their fields but shall reside within the size boundary specified by the data dictionary.

2.6 The entire line shall end with a line termination character i.e. line feed or carriage return.

Example:

0000000001111111111222222222233333333334444444444512345678901234567890123456789012345678901234567890TSTSPON1 Test Monitoring Center<cr>

2.7 The field names do not have to be listed in any particular order within the flat file with the exception of the header.

2.8 The header (hdr data dictionary) is a special data dictionary that contains mandatory fields and must be included as the first group of fields before the test data. The latest version of the header data dictionary can be obtained by contacting the ASTM Test Monitoring Center or by down loading from the TMC data dictionary hdr directory on the World Wide Web pages (http://www.astmtmc.cmu.edu). If multiple tests are transmitted in a flat file, each test must have its own header. The order of the header fields must be maintained. Fields found in the header and also in the body of the test report must contain the same values.Special Rules for header population:

2.8.1 The value of TESTSPON in the header dictionary shall be populated with a value specified by the Receiver of the test.

2.8.2 TESTTYPE shall be taken from the Test Type column in the specific dictionary being used in the body of the report except where a test type code represents multiple test types, the test type of the actual data being transmitted shall be used. This designation shall be taken from one of the listed methods in the description section of the method field in the corresponding test type dictionary. Any imbedded dashes shall be omitted from the designation when populating the test type field.

2.8.3 PURPCODE shall contain 00 for initial transmission 04 for corrected transmissions, 20 for subsequent unchanged transmissions with additional data and 91 for preliminary data transmission.

2.8.4 VERSION shall contain the current version of the data dictionary being used in the body of the report.

2.9 If a field name does not contain a corresponding data item, this implies that the value is NULL. If the field name data item contains a 0 (zero), this value is 0 (zero).

2.10 Repeating Fields:

2.10.1 A repeating field represents data items that contain the same type of information but differ only by time, position or sequential order.

2.10.2 Field names that contain Hxxx or Rxxx in the last four positions of the name are designated repeating fields. The Hxxx is used to represent numeric hourly data fields associated with test hours and the Rxxx represents the generic form of the repeating fields (non -hourly data). The xxx part of the repeating field represents the actual time, position or sequential order of the data item.

2.10.3 The fields Hxxx fields must be expanded in the flat file for the required number of hours

specified by the test procedure and/or test length.

2.10.4 Repeating field groups shall be kept together within the specified group but the order within the group does not have to be maintained. This information is also specified in the Repeating Fields Specification document that is included with each published data dictionary. (See section on Repeating Fields Specifications document)

2.10.5 At least one set of each repeating field must be included in the flat file for fields that do not have a required number of hours specified even if the fields do not contain data. In cases where a repeating set of mnemonics is added to the flat file to meet the requirements of Section 2.10.5, any counter associated with the repeating fields should be set to 0. When a repeating field counter is 0, the corresponding repeating fields should be sent as null values

2.10.6 Repeating fields that do not have requirements specified may be expanded as needed by using a sequential number. For example, OCOMRxxx would be expanded to OCOMR001, OCOMR002 and OCOMR003 for three comments. In

2.10.7 The Repeating fields Specification document describes the expansion required for all repeating fields specified in the corresponding data dictionary. The format of the document is as follows:

Column 1 - 8: Repeating Field NameColumn 10 - 17:The Parent Field Name of the GroupColumn 19 - 26:The Measurement Interval Group NameColumn 27 - 80:Description of Repeating Field

The lines following the Repeating Field name record shall contain the required measurements for the particular field. Multiple 80 character lines can be specification. If required measurements are not specified the field is a variable occurrence field that should be expanded using a incremental counter of 001, 002… for as many fields required to send the data.

Example for handling repeating fields that have a separate counter associated with them follows:

DOWNR001 120DDATR001 20000511DTIMR001 13:34DREAER001 COMMENT ON TESTDOWNR002 150DDATR002 20000512DTIMR002 2:15DREAR002 COMMENT 2 ON TESTDOWNOCR 2

Each set of downtime fields for a given xxx value shall represent a unique downtime occurrence. For example downtime 001 data fields must end in R001.

Parent Fields shall be derived using the first field in a logical block of related fields representative of a group of field on the report forms.

Measurement Interval Group Name shall be derived using the first occurrence of a field with specified measurement intervals and used for every repeating field in the same parent group with the same specified intervals.

Example: Metals Analysis Table sampled every 24 hours

Test Hour TST_H024 TST_H048 TST_H072 TST_H096 TST_H120AG AGWMH024 AGWMH048 AGWMH072 AGWMH096 AGWMH120AL ALWMH024 ALWMH072 ALWMH096 ALWMH120PB PBWMH024 PBWMH048 PBWMH072 PBWMH096 PBWMH120SI SIWMH024 SIWMH072 SIWMH096 SIWMH120

Resulting Repeating Fields Specification

Field_name parent_field_name measurement_interval_namehours_needed

TST_Hxx TST_Hxxx TST_Hxxx024 048 072 096 120AGWMHxxx TST_Hxxx TST_Hxxx024 048 072 096 120ALWMHxxx TST_Hxxx ALWMHxxx024 072 096 120PBWMHxxx TST_Hxxx TST_Hxxx024 048 072 096 120SIWMHxxx TST_Hxxx ALWMHxxx024 072 096 120

2.11 Special Control Fields:

2.11.1 There is a provision for the use of additional fields or control fields to be included in the flat file that may not be specified in the data dictionary. Trading partners should agree on the field names, data type and functionality for these fields. These fields allow a company to customize the flat file to fulfill particular internal requirements. If agreed upon, these fields can be ignored if sent to a trading partner that does not require the fields.

2.12 Graph Data Fields:

2.12.1 Graph data shall be organized into data sets arranged in a columnar fashion. A data set consists of a sequence number plus data values for up to eight data parameters. All fields (mnemonics and values) of each line contained within a data set shall be comma delimited.

2.12.2 A data set shall be composed of a three line preamble section and a data section. The preamble contains the information needed to parse the data into separate columns.

2.12.3 The first and second lines of the preamble shall contain the reserved field UNITS and SAMPLES with data values which define the units of measurement for the Sequence number and the number of samples contained in the data section.

2.12.4 The third line of the preamble shall contain the fields for the data samples contained in the data section, where the first field is the reserved field SEQUENCE.

2.12.5 The data section shall contain one or more (up to the value of SAMPLES) lines of samples.

2.12.6 A sample shall consist of data values with an associated sequence number value. A sample shall have one or more (up to the number of data fields listed in the preamble) values. The first value shall be the value for SEQUENCE. A single decimal point shall be used as the data value of any missing data value.

2.12.7 The relative position of a data field (within the third line of the preamble) shall be used to map (using the comma delimiter) a data definition to data values contained in the line(s) which follow the preamble. The length of any line in a data set shall not exceed 80 characters.

2.12.8 Each data transmission of the graph data shall consist of one or more data sets merged into a single file. A line with the reserved mnemonic VERSION with data value shall be included at the beginning of the graph data file.

2.12.9 A file header (using the standard industry HDR data dictionary) shall be prepended to the graph data file. The value of the TESTTYPE field shall uniquely identify the flat file as the graph data for a given test area (composed by appending the letter 'G' to the report data dictionary TESTTYPE data value).

Section 3Flat File Transmission Protocol

3.0 All Flat Files shall be transmitted to the receivers via (a) Internet HTTP/S or FTP/S applications using the Secure Sockets Layer (SSL) protocol, or (b) via standard Internet File Transfer Protocol (FTP) or Simple Mail Transfer Protocol (SMTP). Please note that both FTP and SMTP are not secure protocols therefore SSL usage is preferred for proprietary data. SSL-enabled browser and server products are commonly available. Refer to Appendix A for more detail on SSL implementation guidelines with an example using HTTP/S.

3.1 The sender may request an electronic confirmation from the receiver. The following two methods for Functional Acknowledgment shall be used:

3.1.1 Receipt Acknowledgment. This provides the sender an acknowledgment that the transmission has been received. It shall be constructed using the Header (hdr) dictionary and the ACK dictionary. It shall contain that header (hdr) from the original transmission.

3.1.2 Process Acknowledgment. This provides the sender with an acknowledgment that shall report any errors found in the transmission after the data has been processed by the receiver. This option is currently under development.

3.1.3 The PURPCODE field in the header (hdr) of the acknowledgement transmission shall contain either 06 specifying confirmation of receipt and processed or 12 specifying confirmation of receipt and not processed.

3.3 When data is being transmitted to the Test Monitoring Center (TMC) the CMIR field in the header (hdr) shall always be populated with the 5 digit value supplied by the TMC.

Section 4Beta Test Procedures

4.0 Every data dictionary that is developed with the intent to use with electronic transmission must first go through a Beta Test process. This process is to insure that the dictionary represents the data as closely as possible before it is used for transmitting data. There are two types of beta testing, initial release, for dictionaries that have never been approved for electronic transfer and testing of dictionaries that have been changed and are currently in production.

4.1 The following are the steps to follow during the initial release beta test process:

4.1.1 The Beta Test Team is formed and shall include at a minimum a "Producer/Sender" of data and a "Consumer/Receiver" of data and any other interested parties.

4.1.2 A Test Team Leader shall be chosen and shall convene all meetings, keep minutes of all meetings and report to the DCC the status of the testing as well as a time line upon completion. The Test Team Leader shall be from an independent laboratory.

4.1.3 The Test Monitoring Center alerts the Beta Team when a dictionary is ready for beta testing. Each member shall review the beta version of the dictionary and submit their comments to the Team Leader. During the review, the data dictionary is to be validated against the ETRTM standards. The leader will compile and disseminate the comments to the team and convene a conference call to discuss.

4.1.4 The results of the conference call are forwarded to the Test Monitoring Center and subsequent modifications are made to the beta dictionary. A new beta version of the dictionary is released.

4.1.5 A flat file is to be built by a sender based on the newly created beta version of the dictionary and sent to the receiver for review. If the flat file is found to be complete and representative of the data then the beta process is complete. If discrepancies are noted, the team may choose to continue review and discussion until all members sign off on the beta version. The test team leader publishes a summary of changes made to the dictionary during the entire beta process.

4.1.6 The Test Monitoring Center will be notified that the Beta Test is complete. Once approved by the surveillance panel, a information letter or memo (for Test Types that are not official test procedures) will be written to release a production version of the test dictionary. The production version of the dictionary will be the same version of the tested beta without the word "BETA".

4.2 The following are the steps to follow during the “currently in production” Beta Test process:

4.2.1 The Test Monitoring Center will be requested by the surveillance panel to make periodic modifications to the report forms and data dictionaries. Once the changes have been made, the DCC is alerted via e-mail that a new BETA version has been created and populated on the Test Monitoring Centers WWW Pages. Included in the e-mail is a specified deadline date for members to reply with one of the following responses: approval of the version, comments and suggestions for change or request for full review by a Beta Test Team.

4.2.2 All members interested in reviewing the changes should do so at this time. If significant problems surface with the changes a formal conference call may be convened to formalize a solution. All comments and question shall be resolved before approval is given. If it is determined that a full review by a Beta Test Team is needed then the Test Team leader is by default the person that led the initial beta test for the given test type. At this point “initial release” type beta testing procedures should be followed.

4.2.3. Once the specified deadline date for comments has passed and/or all comments resolved, the report forms and data dictionary are given to the person at the Test Monitoring Centers responsible for the particular test for Information Letter construction. If a member does not respond by the deadline date, acceptance of the version by this member will be assumed.

4.3 Any change in precision or implied meaning of a data dictionary field must be reviewed by the Test Monitoring Center engineer and possibly by the surveillance panel responsible for the particular test type being tested. Changes with respect to field names and obvious typographical errors can be made without consultation. The surveillance panel must approve the final version of the dictionary before it is released in an information letter.

4.4 When the Information Letter or memo (for Test Types that are not official test procedures) are placed in US Mail an e-mail message is sent to the DCC to alert members that the documents have been mailed. The specified compliance date is also included in the message.

Version: 20030829

Electronic Data Transmission MethodSubcommittee

Appendix I

Electronic Data Transmission Method (ETRTM) GuidelinesUsing Secure Sockets Layer

INTRODUCTION: The Electronic Data Transmission Method (EDTM) described in this document enables information exchange between trading partners using Secure Sockets Layer (SSL).

SSL is used to encrypt network packets between the client desktop and the server. This protects the files from being compromised while traveling over the Internet. By using an SSL certificate from a recognized 3rd party Certificate Authority, the clients are assured they are actually connecting with who they think they are.

Note: This guideline is based on an implementation using specific technologies and infrastructure. While alternate implementations could work, this is the recommended guideline for the ASTM Data Communications Committee.

ARCHITECTURE: The data store utilized by this method is file based. All files are stored in a hierarchical folder structure, which is exposed to users and other automated tools by using HTTP/S protocols. In order for a user or an automated tool to use the SSL system, a user id and password is required; this user information may be stored in various forms: local server id, LDAP (Lightweight Directory Access Protocol) directory, database and even web services such as Microsoft Passport. The implementation of each of these would be dependent on the current infrastructure of the trading partner. There may be advantages and disadvantages of an individual implementation, but for the purposes of this document, they are all acceptable.

The recommended file hierarchy is as follows:

Administrative Level - Top level folder admin access only

Trading Partner folder Level 1(Lab or Data Consumer 1)Sublevel folder(In Box)Sublevel folder(Out Box)

Trading Partner folder Level 1(Lab or Data Consumer 2)Sublevel folder(In Box)Sublevel folder(Out Box)

Trading Partner folder Level 1(Lab or Data Consumer …n)

Electronic Data Transmission MethodSubcommittee

Appendix I

Electronic Data Transmission Method (ETRTM) GuidelinesUsing Secure Sockets Layer

Sublevel folder(In Box)Sublevel folder(Out Box)

The owner/admin of the site will have full access at the top level folder and all folders below.Each trading partner’s folders will have their own authorized user(s). Within this context, users will be able to read and write files. There can be any number of these folders below the top level. The owner/admin will maintain this structure, however it is suggested all participating companies should agree to the same structure and directory naming conventions, as described above in the basic file hierarchy.

Non-administrative users (trading partners) will only have access to their designated folders, and will not see any others.

File Naming Convention:

File Name parts: LLTTTCCC.EEE

Part Description Format SizeLL ACC Lab Code cc 2 charsTTT Content Descriptor ccc 3 charsCCC File Counter - unique per session; or

continuously, recycling after 999 Required for multiple file transfer per transmission.

nnn 3 numbers

EEE File Extension MIME compliant ccc 3 chars

Content Descriptor

Type DescriptionDAT Test Results DataFAC Functional Acknowledgement

File Extension

Ext Description

Electronic Data Transmission MethodSubcommittee

Appendix I

Electronic Data Transmission Method (ETRTM) GuidelinesUsing Secure Sockets Layer

TXT Text

EXAMPLES:

SRDAT001.TXTSRDAT002.TXTSRFAC001.TXT

IMPLEMENTATION EXAMPLE:This EDTM uses HTTPS with a SSL enabled browser for trading partners’ access via the Internet.

You will require some form of an upload component to permit a web browser to upload a file to the web server. This particular component allows control of the security context so that unauthorized users cannot exploit the function to access the server. This component may be purchased or can be built in-house.

Implementation also requires a SSL certificate (VeriSign is a commonly used certificate provider). A separate component should be used to handle authorization and authentication. Users are challenged for an ID and password when first accessing the site. This authenticates the user to the site and allows authorized access to the proper document folders (SiteMinder from Netegrity is an example of this type of software). Native operating system security could also be used.