Information Model for Machine-Tool-Performance Tests

This report specifies an information model of machine-tool-performance tests in the EXPRESS [1] language. The information model provides a mechanism for describing the properties and results of machine-tool-performance tests. The objective of the information model is a standardized, computer-interpretable representation that allows for efficient archiving and exchange of performance test data throughout the life cycle of the machine. The report also demonstrates the implementation of the information model using three different implementation methods.


Objective
This report specifies an information model of machine-tool-performance tests in the EXPRESS modeling language [1]. It is based on the information model described in the Data Specification for Machine Tool Performance Tests, Version 2.3e [2]. The objective of the information model is a standardized, computerinterpretable representation that allows for efficient archiving and exchange of performance test data throughout the life cycle of a machine tool. It serves as a basis for generating database schemas, database calls, and neutral file formats. Performance test data of machine tools is used for machine acceptance, performance tracking, software compensation, and to evaluate the capability of a machine to manufacture a part to specified tolerances.
The information model specifies the test procedure, the test conditions, the equipment, the measurement set-up, and the test results. The model can be used to describe the properties and results of a performance test at a level close to the raw measurement data. The information elements also enable the user to re-create the set-up, equipment settings, and measurement procedure. The model captures key information on the large variety of possible test set-ups and measurement procedures, which is essential for the interpretation of the test results. A subset of the specification can be used to summarize the test, focusing on performance parameters that are estimated from the measurement results.
The information model addresses machine tool properties that are verified by performance tests. It complements machine-tool-specification data that is not tested, e.g., the machine configuration, the workspace, weight and size of the machine, tool holder standard, auxiliary devices, etc. [3].
The information model is intended to serve as the starting point for a future, standardized representation. The model is expected to change and grow based on further review and future implementation experience.
This report is structured as follows: In the remainder of Sec. 1 the problem statement and scope of the information model are defined; modeling language and implementation methods are identified. In Sec. 2 the information model is presented. In Sec. 3 three sample data files are provided. In Sec. 4 software tools that support the implementation of EXPRESS information models are briefed. Section 5 presents the conclusion of this report. An appendix is provided for describing a set of EXPRESS keywords in Sec. 6. The final section lists the references used in this report.

Problem Statement
Today's manufacturing industry greatly relies on computer technology to support activities throughout a product's life cycle. Efficient and distributed access to the performance data of machine tools is important in manufacturing. The results of performance tests are used for machine acceptance, predictive maintenance, error compensation, and to evaluate the capability of a machine to manufacture parts to specified tolerances. A critical enabler to the efficient interchange and storage of performance data is a unified information model for the results and properties of performance tests.
Currently, there is no agreed-upon mechanism for representing the properties and results of machine-toolperformance tests [2]. There exists a variety of software packages for the performance evaluation of machine tools. They usually have been developed by the manufacturer of a particular measurement device, such as a laser interferometer or a ball bar, and are tailored to that particular instrument. The software packages employ different data models and store the data in files using vendor-specific formats. This complicates data exchange, data storage in databases, and use of the data by third-party software. Furthermore, the stored data is often limited to the data required to produce the graphs and numbers specified in the various standards for machine-tool-performance evaluation (e.g., [4,5,6]). This may result in inefficient access or even loss of the additional data that is required for other applications, such as virtual machining and software error compensation. Finally, not all tests described in the standards are addressed by existing software for machine tool testing. This is often the case for tests that require generic equipment, such as displacement indicators. Users have created their own "in-house" methods, often using spreadsheets, to store the properties and results of these tests, often on an ad-hoc basis.

Scope
This specification supports the majority of instrumented, machine-tool-performance tests defined in the American [4,5] and international [6]  For these tests the following information is described: 1) Date and time of the test. 2) Identification of the machine tool on which the test was performed. 3) Indication as to why the test was performed. 4) The operator who performed the test. 5) The machine status and environmental conditions during the test. 6) The standard in which the test is defined. 7) The equipment and software used to perform the test. 8) The measurement set-up and operating parameters. 9) The raw measurement data. 10) The calculated performance parameters.

Modeling Language and Implementation Methods
The information model presented in this report is in the EXPRESS language. The EXPRESS modeling language [1] was developed as part of the International Organization for Standardization (ISO) Standard 10303, commonly known as the Standard for the Exchange of Product Model Data (STEP) [7]. STEP is the result of an effort to develop a mechanism for digitally representing the physical and functional characteristics of a product throughout the product's life cycle. STEP includes information models and mechanisms for representing the models and related data. EXPRESS is a formally specified structured language. EXPRESS models have an object-oriented flavor. The reason EXPRESS is chosen here is three-fold: EXPRESS is primarily an information modeling language, EXPRESS is a textual representation that permits machine processing of the specification, and EXPRESS consists of language elements that allow unambiguous object definitions and specification of constraints on the objects defined.
An information model provides a sharable, stable, and organized structure of information requirements. It is developed to be independent from implementations using different data format structures. Implementation independence allows users to select their implementation methods. The selection of an implementation method is heavily dependent on the target environment where the application system resides, but the information contained in the model is not dependent on the target environment if the modeling is done properly. Currently, the implementation methods used by the manufacturing community include: 1) data transfer via a working form, which is a structured, in-memory representation of data.
2) data transfer via an exchange file, which is a file with a predefined structure or format.
3) data transfer using a database management system [8].
STEP introduced the 10303 Exchange Structure in ISO 10303-21, or the Part 21 file, as an implementation method for actual EXPRESS models [9]. A Part 21 file contains instances of the various entities defined by the EXPRESS information model. The Part 21 file format is just one of the implementation methods for representing data in accordance with the EXPRESS information models. Tools that support the implementation of EXPRESS information models are briefly described in Sec. 4.

Information Model
In this section, an EXPRESS information model for representing the properties and results of machinetool-performance tests is presented. Section 2.1 describes the structure of data requirements. The schema is presented in detail in Sec. 2.2. Appendix A contains the listing of EXPRESS keywords that are used in the schema.

Structure of Data Requirements
The information model presented in Sec. 2.2 is based on the "Data Specification for Machine Tool Performance Tests, Version 2.3e" [2]. The large variety of addressed performance tests are classified into four groups: 1) Circular: tests where error motions are measured at points on a circular path in the machine workspace.
2) Line: tests where error motions are measured at points on a line in the space spanned by the positioning axes of the machine (e.g., positioning accuracy, axis geometry, diagonal displacement accuracy, axis alignment, and thermal distortion caused by axis motion).
3) Point: tests where error motions are measured at a single point in the space spanned by the positioning axes of the machine (e.g., subsystem repeatability, spindle axis of rotation, spindle thermal stability, and Environmental Temperature Variation Error).

4) Compliance
: tests for the compliance and hysteresis of the machine under static loads.
The specifications for other performance tests, e.g., computer numerical control (CNC) performance tests, machining tests, and tests addressing the measurement capabilities of a machine tool, are under development and will follow the structure outlined below. Figure 1 shows the relationships among the major entities in the information model. The figure is presented by EXPRESS-G 1 [1], a graphical subset of the EXPRESS language. The TESTS entity is a list of TEST entities, each describing the properties and results of a performance test. The TEST entity contains the MACHINE entity identifying the tested machine. This is achieved by either a unique identification (ID) or a set of properties: manufacturer, model, and serial number. A unique ID as an alternative to a set of properties is also given to several other entities in the model.
Most of the parameters that describe the design of a test are contained in three entities: CONDITIONS, EQUIPMENT, and SETUP. The CONDITIONS entity describes the status of the machine and its environment during the test. The parameters of this entity apply to 1 EXPRESS-G is represented by graphic symbols forming a diagram. The definitions of data types and schemas within a diagram are denoted by boxes which enclose the name of the item being defined. The relationships between the items are denoted by the lines joining the boxes. Differing line styles provide information on the kind of definition or relationships. For example, a relationship for an optional attribute of an entity data type is presented as a dashed line. An inheritance relationship (i.e., a subtype and supertype relationship) is presented as a thick line. most tests. By contrast, the content of the EQUIPMENT and SETUP entities varies depending on the type of test. The EQUIPMENT entity describes the properties and (factory) settings of a kit of instruments and artifacts assembled for a specific type of test. The entity usually does not change once such a kit has been defined. The SETUP entity contains parameters that describe the tested machine property, the set-up, and the measurement procedure. The parameter values usually vary unless a test is repeated. The majority of the information contained in the SETUP entity is not dependent on the content of the EQUIPMENT entity.
The results of a test are contained in two entities: RUN_DATA and RESULT. RUN_DATA contains the measurement data of an individual run. A run is a specific motion pattern of the machine during which errors are measured. A performance test usually consists of several runs that can only differ in the approach direction to the target points. A RESULT entity contains performance parameters that are estimated from the data obtained in one or more runs. A test can have multiple RESULT entities that may differ because of differing physical testing conditions, such as direction of probe approach.
The use of a particular system of measurement units is site-specific. However, use of mixed units will complicate the exchange and storage of data. Therefore, the units of measurement values used in this information model are predefined [2]. It is assumed that the application software will make the desired conversions to and from these units.

EXPRESS Information Model
This subsection describes the detailed information for the schema of machine-tool-performance tests. The schema name is MACHINE_TOOL_ PERFORMANCE_TESTS. An EXPRESS schema is composed of declarations of types, entities, constraints, and their relationships. The concept of a type in EXPRESS is the same as that of a data type in a standard programming language. It defines the kind of values that an object may assume. Entities are the focal point of an EXPRESS information model. An entity declaration describes the information content of an object, as well as some of the constraints on the objects.
In EXPRESS language, a "remark" is used for documentation and is not significant as a language element. The character pair, "(" and "*", is used to denote the start of an embedded remark, and the character pair, "*" and ")", is used to denote its end. This character pair is also known as a "token." An embedded remark may appear between any two tokens. In this report, the documentation is presented as embedded remarks. Consequently, if we were to begin the report with "(*", the entire report could be read into an EXPRESS parser for further analysis.

Entity Definitions
The entities are formally defined in this subsection. The entities presented here are in the "top-down" order, i.e., primitive type definitions are presented last.

Type Definitions
The types are formally defined in this subsection and they are presented in alphabetical order.

Implementation Samples
The example shown in this section is for a dynamic, circular test in the XY -plane of a milling machine. The measurements are performed with a ball bar. The programmed circle consists of line segments (an option mentioned in Appendix E8.2 of the ASME B5.57 standard on turning centers [5]). A calibrator is previously used to determine the absolute length of the ball bar.
Three implementation samples on the EXPRESS model are presented for the same data. Section 3.1 demonstrates the implementation using the ISO 10303-21 Exchange Structure [9]. Section 3.2 demonstrates an XML (the Extensible Markup Language) [10] implementation. Section 3.3 demonstrates the implementation using a relational database. All samples have been generated manually.

ISO 10303 Part 21 Exchange Structure
ISO 10303-21 specifies an exchange structure of product data for which the conceptual model is speci-fied in the EXPRESS language. The file format is suitable for transfer among computer systems. The exchange structure is designed to facilitate parsing by software.
The following is a sample of an exchange structure based on the ISO 10303-21, Clear Text Encoding Of the Exchange Structure [9]. Each Part 21 file format may be considered a continuous stream. This exchange structure consists of two sections: the header section and the data section. The header section contains information that is applicable to the entire exchange file. The data section contains instances of entities that correspond to the EXPRESS schema governing the exchange structure as specified in the header section. An entity instance name is identified by a number sign (ն), followed by a unique entity name, which is an unsigned integer of 1 or more digits. When a value is not provided for an optional attribute, the attribute value is encoded as the dollar sign ($). Both forward and backward references are permitted. A comment is encoded as a solidus asterisk (/*) followed by any number of characters, and terminated by an asterisk solidus (*/).  STANDARD  TEMP_SENSOR_DEF  TEMP_SENSOR  TEST_DEF  TEST  TIME_DEF  TIME  TOOL_VECTOR_DEF  TOOL_VECTOR   */  ISO-10303-21;  HEADER;  FILE_DESCRIPTION (('THIS FILE CONTAINS A SAMPLE CIRCULAR TEST')

XML Document
XML, an extensible markup language, is a universal format for structured documents and data on the Web [10]. The language helps make information exchange among a globally distributed computing environment possible. XML allows precise encoding of structured information. The XML data file (below) contains both data and an indication of the meaning of the data. XML is for the digital representation of documents.
The following is an XML document sample. This XML document is well-formed, which means that the tags are properly constructed. This XML document, however, does not contain a document type definition 2 (DTD). Our intention for this subsection is to demonstrate the XML implementation of the EXPRESS 2 A document type definition (DTD) is the set of rules for using XML to represent documents of a particular type. DTD is a series of definitions for element types, attributes, entities, and notations. DTD is optional for an XML document. Documents that do not have a DTD are not really invalid, but they are not valid either, because they cannot be validated against a DTD. model, the development of the DTD will be the topic for another report. An XML document is composed of a series of characters. It has two main parts: a prolog and a document instance. The prolog is optional, and describes the XML version, DTD, and other characteristics of the document. The document instance follows the prolog and contains the actual document data organized as a hierarchy of elements. An XML source is made up of XML elements, each of which consists of a start-tag, the element content, and an end-tag. An XML start-tag consists of the less-than symbol (<), the name of the element, and a greater-than symbol (>). Start-tags can also include attributes. An XML end-tag consists of the string "</", the same element name as in the start-tag, and a greater-than symbol (>).

Relational Tables
Database technology has evolved rapidly. The evolution has moved from simple files to the use of network and hierarchical database management systems, and to today's relational systems and object-oriented systems. Evolving technology has made data sharing a realistic alternative. Moreover, today's generation of powerful, inexpensive workstation computers enables users to design software that maintains and distributes data quickly and inexpensively. Relational database management systems are generally desirable for data transfer for the manufacturing community.
All information in a relational database is represented explicitly as values in tables. The Structured Query Language (SQL) [11] was developed to service a relational database. SQL was originally made an ANSI (the American National Standards Institute) standard in 1986, was revised and extended in 1989, and accepted by the ISO in 1992. SQL is a set of commands that are used to create and maintain database tables, manipulate and retrieve data from the relational databases.
The following is a sample of relational tables for the EQUIPMENT entity. These tables have been manually mapped from the respective portion of the EXPRESS information model. Our intention for this subsection is to demonstrate the relational database implementation of the EXPRESS model, the development of the SQL statements that map the complete MACHINE_TOOL_PERFORMANCE_TESTS schema will be the topic for another report. In the SQL statements below, the OID_MAPPING table contains identity information for every EXPRESS object in the database and "OID" stands for Object Identifier. CREATE  "BALL_BAR" 100 "LIST_OF_COMPONENT"

Use of the Information Model
The information model, MACHINE_TOOL_ PERFORMANCE_TESTS, presented in Sec. 2 specifies the information necessary to represent the properties and results of machine-tool-performance tests. The model has been successfully parsed using fedex, one of the applications in the NIST EXPRESS Toolkit [12]. The NIST EXPRESS Toolkit is a software library for building software tools for manipulating EXPRESS information models, and fedex is the tool that reports syntactic and semantic errors in EXPRESS schemas. The MACHINE_TOOL_PERFORMANCE_TESTS information model is independent of any implementation method. Several commercial and non-commercial software tools exist to support the implementation of EXPRESS information models. A document describing software tools and services for EXPRESS was published by P. R. Wilson [13] and is available from the ISO TC184/SC4 homepage [14]. NIST has released a STEP Toolset for manipulating STEP data; the Toolset is in the public domain and is also available on the Table 4. Table of COMPONENT   COMPONENT-ID  ID  DESCRIPTION  MANUFACTURER  COMPONENT-MODEL  SERIAL-NUMBER   6 -" BALL_BAR" " XYZ" " ABC1" " 123" 7 -" CALIBRATOR" " XYZ" " ABC2" " 456" [14]. The implementors can take advantage of these software tools to generate various types of data structures from the information model in order to benefit the exchange of machine-toolperformance data.

Conclusion
This report describes the approach being taken by NIST in developing a neutral format for exchanging machine-tool-performance data. An information model of machine-tool-performance tests in EXPRESS has been developed. The implementations of the information model using the STEP exchange structure, XML, and SQL have been demonstrated. The information model will continue to evolve based on experience and feedback from others involved in this effort. Our objective is to promote the information model to an official standard. Broader participation in this effort will help the standardization work proceed more quickly and will also enhance the system performance and user satisfaction.

Appendix A. List of EXPRESS Key Words
The following is the list of EXPRESS key words that are used in the information model in this report. Brief definitions of these keywords are summarized here for readers' convenience. For further information, refer to "The EXPRESS Language Reference Manual" [1].
AND-The reserve word AND is an AND operator. The AND operator requires two logical operands and evaluates to a logical value.
BOOLEAN-A BOOLEAN data type represents a TRUE or FALSE value.

END_ENTITY-
The key word END_ENTITY is used to terminate an entity declaration.

END_SCHEMA-
The key word END_SCHEMA is used to terminate a schema declaration.

END_TYPE-
The key word END_TYPE is used to terminate a type declaration.

ENTITY-
The key word ENTITY is used to specify an entity type. An entity type characterizes a collection of real-world physical or conceptual objects that have common properties. Any entity declared in a schema can be used as the data type of an attribute, local variable, or parameter. Using an entity as an attribute's data type establishes a relationship between the two entities.

ENUMERATION-
The key word ENUMERATION is used to specify an enumeration data type. An enumeration data type is an ordered set of values represented by names. Each enumeration item belongs only to the data type that defines it and must be unique within that type definition.

FALSE-
The reserve word FALSE is a LOGICAL constant representing the logical notion of falsehood. It is compatible with the BOOLEAN and LOGICAL data types.

INTEGER-
The key word INTEGER is used to specify an integer data type. An integer data type represents a value of an integer number, the magnitude of which is unconstrained.

LIST-
The key word LIST is used to specify a list data type. A list data type represents an ordered collections of like elements. The number of elements that can be held in a list can optionally be specified. If the size is not specified, the list can hold any number of elements. Duplicate elements are allowed in a list.

OF-
The key word OF is used together with other key words such as BAG, LIST, SET, ENUMERATION, SUBTYPE, SUPERTYPE, etc.

OPTIONAL-
The key word OPTIONAL is used to indicate that the attribute need not have a value in order for an instance of that entity to be valid. In a given entity instance, an attribute marked as optional may have no actual value, in which case the value is said to be null. The null value function (NVL), which returns either the input value or an alternate value in the case where the input has a null value, may be used when a null value is unacceptable.
OR-The reserve word OR is an OR operator. The OR operator requires two logical operands and evaluates to a logical value.

REAL-
The key word REAL is used to specify a real data type. A real data type represents rational, irrational, and scientific real numbers. Rational and irrational numbers have infinite resolution and are exact. Scientific numbers represent values that are known only to a specified precision.

SCHEMA-
The key word SCHEMA is used to specify a schema type. A schema declaration creates a new scope in which the following objects may be declared: constant, entity, function, procedure, rule, and type.

STRING-
The key word STRING is used to specify a string data type. A string data type represents a sequence of zero or more characters.

TRUE-
The reserve word TRUE is a LOGICAL constant representing the logical notion of truth. It is compatible with the BOOLEAN and LOGICAL data types.

TYPE-
The key word TYPE is used to specify a defined data type. A defined data type is a user extension to the set of standard data types. A defined data type can be used as any other data type by referencing the name given to it.

UNIQUE-
The key word UNIQUE is used to specify a uniqueness rule. A uniqueness rule specifies either a single attribute name or a list of two or more attribute names. A rule that specifies a single attribute name is a "simple uniqueness constraint'', requiring that any value of that attribute is associated with only one instance of that entity type. A rule that specifies two or more attribute names is a "joint uniqueness constraint," requiring that any set of values, one from each of the named attributes, is associated with only one instance of that entity type.

WHERE-
The key word WHERE is used to specify domain rules. Domain rules constrain the values of individual attributes or combinations of attributes for every entity instance.