MTConnect Specification and Materials


Overview of what to expect in this document. Overview of what to expect in this document. Overview of what to expect in this document. Overview of what to expect in this document. Overview of what to expect in this document. Overview of what to expect in this document. Overview of what to expect in this document. Overview of what to expect in this document. Overview of what to expect in this document. Overview of what to expect in this document. Overview of what to expect in this document. Overview of what to expect in this document. 

Prepared for: MTConnect Institute

Prepared by: William Sobel

Prepared on: August 31, 2014

AMT - The Association For Manufacturing Technology (“AMT”) owns the copyright in this MTConnect® Specification or Material.  AMT grants to you a non-exclusive, non- transferable, revocable, non-sublicensable, fully-paid-up copyright license to reproduce, copy and redistribute this MTConnect® Specification or Material, provided that you may only copy or redistribute the MTConnect® Specification or Material in the form in which you received it, without modifications, and with all copyright notices and other notices and disclaimers contained in the MTConnect® Specification or Material.

If you intend to adopt or implement an MTConnect® Specification or Material in a product, whether hardware, software or firmware, which complies with an MTConnect® Specification, you SHALL agree to the MTConnect® Specification Implementer License Agreement (“Implementer License”) or to the MTConnect® Intellectual Property Policy and Agreement (“IP Policy”).  The Implementer License and IP Policy each sets forth the license terms and other terms of use for MTConnect® Implementers to adopt or implement the MTConnect® Specifications, including certain license rights covering necessary patent claims for that purpose.  These materials can be found at www.MTConnect.org, or by contacting Paul Warndorf atmailto:pwarndorf@mtconnect.hyperoffice.com.

MTConnect® Institute and AMT have no responsibility to identify patents, patent claims or patent applications which may relate to or be required to implement a Specification, or to determine the legal validity or scope of any such patent claims brought to their attention.  Each MTConnect® Implementer is responsible for securing its own licenses or rights to any patent or other intellectual property rights that may be necessary for such use, and neither AMT nor MTConnect® Institute have any obligation to secure any such rights. 

This Material and all MTConnect® Specifications and Materials are provided “as is” and MTConnect® Institute and AMT, and each of their respective members, officers, affiliates, sponsors and agents, make no representation or warranty of any kind relating to these materials or to any implementation of the MTConnect® Specifications or Materials in any product, including, without limitation, any expressed or implied warranty of noninfringement, merchantability, or fitness for particular purpose, or of the accuracy, reliability, or completeness of information contained herein. In no event shall MTConnect® Institute or AMT be liable to any user or implementer of MTConnect® Specifications or Materials for the cost of procuring substitute goods or services, lost profits, loss of use, loss of data or any incidental, consequential, indirect, special or punitive damages or other direct damages, whether under contract, tort, warranty or otherwise, arising in any way out of access, use or inability to use the MTConnect® Specification or other MTConnect® Materials, whether or not they had advance notice of the possibility of such damage.

 

Table of Contents

 

1       Overview.................................................................................................................................. 1

1.1         MTConnect® Document Structure.............................................................................................. 1

1.2         MTConnect Versions and Backward Compatibility....................................................................... 1

2       Purpose of This Document....................................................................................................... 3

2.1         Terminology.......................................................................................................................... 3

2.2         XML Terminology.................................................................................................................. 3

2.3         Markup Conventions................................................................................................................ 8

2.4         Document Conventions............................................................................................................ 8

2.5         Document Style Guidelines....................................................................................................... 9

2.6         Units................................................................................................................................... 10

2.7         Referenced Standards and Specifications..................................................................................... 10

3       Architectural Overview......................................................................................................... 11

3.1         Request Structure................................................................................................................... 11

3.2         Process Workflow.................................................................................................................. 11

3.2.1          Agent Initialization......................................................................................................... 12

3.2.2          Application Communication.............................................................................................. 13

3.3         MTConnect Agent Data Storage............................................................................................... 14

3.4         MTConnect Agent Asset Storage.............................................................................................. 15

4       Reply XML Document Structure........................................................................................... 18

4.1      MTConnectDevices.......................................................................................................... 18

4.1.1          MTConnectDevices Elements....................................................................................... 19

4.2      MTConnectStreams.......................................................................................................... 19

4.2.1          MTConnectStreams Elements....................................................................................... 20

4.3      MTConnectAssets............................................................................................................ 20

4.4      MTConnectError.............................................................................................................. 22

4.4.1          MTConnectError Elements........................................................................................... 23

4.5         Header................................................................................................................................. 23

4.6         MTConnectDevices Header...................................................................................................... 24

4.6.1          Header attributes:........................................................................................................... 24

4.6.2          Header Elements............................................................................................................. 24

4.6.3          AssetCount attributes:..................................................................................................... 24

4.7         MTConnectError Header......................................................................................................... 25

4.8         MTConnectStreams Header..................................................................................................... 25

4.9         All Header Attributes.............................................................................................................. 25

5       Protocol.................................................................................................................................. 30

5.1         Standard Request Sequence...................................................................................................... 30

5.2         Probe Requests...................................................................................................................... 33

5.3         Sample Request..................................................................................................................... 35

5.3.1          Parameters.................................................................................................................... 37

5.4         Current Request..................................................................................................................... 38

5.4.1          Parameters.................................................................................................................... 38

5.4.2          Getting the State at a Sequence Number............................................................................. 38

5.4.3          Determining Event Duration............................................................................................. 42

5.5         Streaming............................................................................................................................. 44

5.6         Asset Requests...................................................................................................................... 47

5.7         HTTP Response Codes and Error.......................................................................................... 48

5.7.1          MTConnectError.................................................................................................... 48

5.7.2          Errors.................................................................................................................... 49

5.7.3          Error...................................................................................................................... 49

5.8         Protocol Details..................................................................................................................... 50

5.8.1          Buffer Semantics............................................................................................................. 51

5.8.2          Buffer Windows.............................................................................................................. 52

5.9         Request without Filtering........................................................................................................ 53

5.10      Request with Filtering using Path Parameter............................................................................... 56

5.11      Fault Tolerance and Recovery.................................................................................................. 59

5.11.1       Application Failure......................................................................................................... 59

5.11.2       Agent Failure................................................................................................................. 61

5.11.3       Data Persistence and Recovery.......................................................................................... 62

5.12      Unavailability of Data............................................................................................................. 63

5.12.1       Examples....................................................................................................................... 64

5.12.2       Constant valued data items............................................................................................... 66

Appendices.................................................................................................................................... 67

A.          Bibliography....................................................................................................................... 67

B.          Discovery............................................................................................................................ 69

B.1.     Physical Architecture......................................................................................................... 69

 

 

 

Table of Figures

Figure 1: Agent Initialization......................................................................................................... 12

Figure 2: Application Communication.......................................................................................... 13

Figure 3: MTConnectDevices structure........................................................................................ 18

Figure 4: MTConnectStreams structure........................................................................................ 19

Figure 5: MTConnectAsset structure........................................................................................... 20

Figure 6: MTConnectError structure............................................................................................ 22

Figure 7: Header Schema Diagram for MTConnectError.......................................................... 27

Figure 8: Header Schema Diagram for MTConnectStreams..................................................... 25

Figure 9: Application and Agent Conversation............................................................................. 32

Figure 10: Sample Device Organization......................................................................................... 36

Figure 11: Example Buffer 1.......................................................................................................... 51

Figure 12: Buffer Semantics 2........................................................................................................ 52

Figure 13: Sample Data in an Agent.............................................................................................. 53

Figure 14: Example #1 for Sample from Sequence #101................................................................ 54

Figure 15: Example #1 for Sample from Sequence #113................................................................ 55

Figure 16: Example #1 for Sample from Sequence #124................................................................ 56

Figure 17: Example #2 for Sample from Sequence #101 with Path............................................... 57

Figure 18: Example #2 for Sample from Sequence #112 with Path............................................... 58

Figure 19: Example #2 for Sample from Sequence #123 with Path............................................... 59

Figure 20: Application Failure and Recovery................................................................................ 60

Figure 21: Agent Failure and Recovery......................................................................................... 62

Figure 22: Unavailable Data from Machine................................................................................... 64

Figure 23: Shop Illustration........................................................................................................... 69

 

 

1       Overview

MTConnect is a standard based on an open protocol for data integration. MTConnect® is not intended to replace the functionality of existing products, but it strives to enhance the data acquisition capabilities of devices and applications and move toward a plug-and-play environment to reduce the cost of integration.

MTConnect® is built upon the most prevalent standards in the manufacturing and software industry, maximizing the number of tools available for its implementation and providing the highest level of interoperability with other standards and tools in these industries.

To facilitate this level of interoperability, a number of objectives are being met. Foremost is the ability to transfer data via a standard protocol which includes:

   A device identity (i.e. model number, serial number, calibration data, etc.).

   The identity of all the independent components of the device.

   Possibly a device’s design characteristics (i.e. axis length, maximum speeds, device thresholds, etc.).

   Most importantly, data captured in real or near-real-time (i.e. current speed, position data, temperature data, program block, etc.) by a device that can be utilized by other devices or applications (e.g. utilized by maintenance diagnostic systems, management production information systems, CAM products, etc.).

The types of data that may need to be addressed in MTConnect® could include:

   Physical and actual device design data

   Measurement or calibration data

   Near-real-time data from the device

To accommodate the vast amount of different types of devices and information that may come into play, MTConnect® will provide a common high-level vocabulary and structure.

The first version of MTConnect® focused on a limited set of the characteristics mentioned above that were selected based on the fact that they could have an immediate effect on the efficiency of operations.  Subsequent versions of the standard have and will continue to add additional functionality to more completely define the manufacturing environment.

1.1      MTConnect® Document Structure

The MTConnect® specification is subdivided using the following scheme:

Part 1: Overview and Protocol

Part 2: Components and Data Items

Part 3: Streams, Events, Samples, and Condition

Part 4: Assets

 

These four documents are considered the bases of the MTConnect standard. Information applicable to basic machine and device types will be included in these documents.    Additional parts to the standard will be added to provide information and extensions to the standard focused on specific devices, components, or technologies considered requiring separate emphasis.   All information specific to the topic of each additional part MUST be included within that document even when it is a subject matter of one of the base parts of the standard.

 

Documents will be named (file name convention) as follows:

MTC_Part_<Number>_<Description>.doc.

For example, the file name for Part 2 of the standard is MTC_Part_2_Components.doc.

All documents will be developed in Microsoft® Word format and released in Adobe® PDF format.

1.2      MTConnect Versions and Backward Compatibility

MTConnect® uses a three digit version numbering system consisting of a major.minor.revision, for example, a version number 1.1.4 would be major=1, minor=2, and revision=4. The major revision changes indicate that major changes to the standard have been made and backward compatibility MAY not be possible. This means that the schema may have changed in ways that will require the applications to change the way the request and interpret the data so they MUST be fully version aware and using the same requests across major versions MAY NOT work. The standard will still try to maintain as much backward compatibility as possible to preserve the investment in existing software development.

A minor version will introduce new components and data items and minor structural changes, additions only. With a minor release applications will only require minor changes to accept the changes and will still be able to function with older agents. Protocol changes will be kept to a minimum so application can use the same request semantics across versions. A minor version change will only DEPRECATE existing content and mark it for remove in future major version changes. This allows previous implementations to use new components and still function correctly.

Both major and minor changes MUST require a ninety day review of the standard by the technical advisory group (TAG). This requirement is to ensure that the additional are free from any intellectual property or copyright violations.

Revision changes will be editorial corrections and will introduce no new functionality. These changes MUST NOT require any changes to the application and implementation of the supporting software. Revisions MUST NOT require any review period since there is no new structure or functionality introduced.

2       Purpose of This Document

The four base MTConnect® documents are intended to:

 

   define the MTConnect® standard;

   specify the requirements for compliance with the MTConnect® standard;

   provide engineers with sufficient information to implement Agents for their devices;

   provide developers with the necessary guidelines to use the standard to develop applications.

Part 1 of the MTConnect Standard provides an overview of the MTConnect Architecture and Protocol; including communication, fault tolerance, connectivity, and error handling requirements.

Part 2 of the MTConnect® standard focuses on the data model and description of the information that is available from the device.  The descriptive data defines how a piece of equipment should be modeled, the structure of the component hierarchy, the names for each component (if restricted), and allowable data items for each of the components.

Part 3 of the MTConnect standard focuses on the data returned from a current or sample request (for more information on these requests, see Part 1). This section covers the data representing the state of the machine. 

Part 4 of the MTConnect® standard provides a semantic model for entities that are used in the manufacturing process, but are not considered to be a device nor a component.  These entities are defined as MTConnect® Assets.  These assets may be removed from a device without detriment to the function of the device, and can be associated with other devices during their lifecycle.  The data associated with these assets will be retrieved from multiple sources that are responsible for providing their knowledge of the asset.  The first type of asset to be addressed is Tooling.

2.1      Terminology

Adapter                An optional software component that connects the Agent to the Device.

Agent                    A process that implements the MTConnect® HTTP protocol, XML generation, and MTConnect protocol.

Alarm                   An alarm indicates an event that requires attention and indicates a deviation from normal operation.  Alarms are reported in MTConnect as Condition.

Application          A process or set of processes that access the MTConnect® Agent to perform some task.

Attribute              A part of an XML element that provides additional information about that XML element. For example, the name XML element of the Device is given as <Device name="mill-1">...</Device>

CDATA                The text in a simple content element. For example, This is some text, in <Message ...>This is some text</Message>.

Component          A part of a device that can have sub-components and data items.  A component is a basic building block of a device.

Controlled Vocabulary   The value of an element or attribute is limited to a restricted set of possibilities. Examples of controlled vocabularies are country codes: US, JP, CA, FR, DE, etc…

Current                A snapshot request to the Agent to retrieve the current values of all the data items specified in the path parameter.  If no path parameter is given, then the values for all components are provided.

Data Item             A data item provides the descriptive information regarding something that can be collected by the Agent.

Device                  A piece of equipment capable of performing an operation.  A device may be composed of a set of components that provide data to the application.  The device is a separate entity with at least one component or data item providing information about the device.

Discovery             Discovery is a service that allows the application to locate Agents for devices in the manufacturing environment.  The discovery service is also referred to as the Name Service.

Event                    An event represents a change in state that occurs at a point in time. Note: An event does not occur at predefined frequencies.

HTTP                   Hyper-Text Transport Protocol.  The protocol used by all web browsers and web applications.

Instance               When used in software engineering, the word instance is used to define a single physical example of that type.  In object-oriented models, there is the class that describes the thing and the instance that is an example of that thing.

LDAP                    Lightweight Directory Access Protocol, better known as Active Directory in Microsoft Windows.  This protocol provides resource location and contact information in a hierarchal structure.

MIME                   Multipurpose Internet Mail Extensions.  A format used for encoding multipart mail and http content with separate sections separated by a fixed boundary.

Probe                    A request to determine the configuration and reporting capabilities of the device.

REST                    REpresentational State Transfer.  A software architecture where the client and server move through a series of state transitions based solely on the request from the client and the response from the server.

Results                 A general term for the SamplesEvents, and Condition contained in a ComponentStream as a response from a sample or current request.

Sample                 A sample is a data point from within a continuous series of data points.  An example of a Sample is the position of an axis.

Socket                  When used concerning inter-process communication, it refers to a connection between two end-points (usually processes).  Socket communication most often uses TCP/IP as the underlying protocol.

Stream                 A collection of Events, Samples, and Condition organized by devices and components.

Service                 An application that provides necessary functionality.

Tag                       Used to reference an instance of an XML element.

TCP/IP                 TCP/IP is the most prevalent stream-based protocol for inter-process communication.  It is based on the IP stack (Internet Protocol) and provides the flow-control and reliable transmission layer on top of the IP routing infrastructure.

URI                       Universal Resource Identifier.  This is the official name for a web address as seen in the address bar of a browser.

UUID                    Universally unique identifier.

XPath                   XPath is a language for addressing parts of an XML Document.  See the XPath specification for more information. http://www.w3.org/TR/xpath

XML                     Extensible Markup Language. http://www.w3.org/XML/

XML Schema      The definition of the XML structure and vocabularies used in the XML Document.

XML Document  An instance of an XML Schema which has a single root XML element and conforms to the XML specification and schema.

XML Element      An element is the central building block of any XML Document.  For example, in MTConnect® the Device XML element is specified as <Device >...</Device>

XML NMTOKEN    The data type for XML identifiers.  It MUST start with a letter, an underscore “_” or a colon “:” and then it MUST be followed by a letter, a number, or one of the following “.”, ”-“, ”_”, “:”.  An NMTOKEN cannot have any spaces or special characters.

2.2        XML Terminology

In the document there will be references to XML constructs, including elements, attributes, CDATA, and  more. XML consists of a hierarchy of elements. The elements can contain sub-elements, CDATA, or both. For this specification, however, an element never contains mixed content or both sub-elements and CDATA. Attributes are additional information associated with an element. The textual representation of an element is referred to as a tag. In the example:

 <Foo name=”bob”>Ack!</Foo>

An XML element consists of a named opening and closing tag. In the above example, <Foo...> is referred to as the opening tag and </Foo> is referred to as the closing tag. The text Ack! in between the opening and closing tags is called the CDATACDATA can be restricted to certain formats, patterns, or words. In the document when it refers to an element having CDATA, it indicates that the element has no sub-elements and only contains data.

When one looks at an XML Document there are two parts. The first part is typically referred to as an XML declaration and is only a single line. It looks something like this:

2.   <?xml version="1.0" encoding="UTF-8"?>

This line indicates the XML version being used and the character encoding. Though it is possible to leave this line off, it is usually considered good form to include this line in the beginning of the document.

Every XML Document contains one and only one root element. In the case of MTConnect, it is the MTConnectDevicesMTConnectStreamsMTConnectAssets, orMTConnectError element. When these root elements are used in the examples, you will sometimes notice that it is prefixed with mt as in mt:MTConnectDevices. The mt is what is referred to as a namespace alias and it refers to the urn urn:mtconnect.org:MTConnectDevices:1.2 in the case of an MTConnectDevices document. The urn is the important part and MUST be consistent between the schema and the XML document. The namespace alias will be included as an attribute of the XML element as in:

1.  <MTConnectDevices

2.    xmlns:m="urn:mtconnect.org:MTConnectDevices:1.2"

3.    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

4.    xmlns="urn:mtconnect.org:MTConnectDevices:1.2"

5.    xsi:schemaLocation="urn:mtconnect.org:MTConnectDevices:1.2
          http://www.mtconnect.org/schemas/MTConnectDevices_1.2.xsd
">

 

In the previous example, the alias m refers to the MTConnectDevices urn. This document also contains a default namespace on line 4 which is specified with an xmlns attribute without an alias. There is an additional namespace that is always included in all XML documents and usually assigned the alias xsi. This namespace is used to refer to all the standard XML data types prescribed by the W3C. An example of this is the xsi:schemaLocation attribute that tells the XML parser where the schema can be found.

 In XML, to allow for multiple XML Schemas to be used within the same XML Document, a namespace will indicate which XML Schema is in effect for this section of the document. This convention allows for multiple XML Schemas to be used within the same XML Document, even if they have the same element names. The namespace is optional and is only required if multiple schemas are required.

An attribute is additional data that can be included in each element. For example, in the following MTConnect® DataItem,  there are several attributes describing the DataItem:

3.   <DataItem name=”Xpos” type=”POSITION” subType=”ACTUAL” category=”SAMPLE” />

The nametypesubType, and category are attributes of the element. Each attribute can only occur once within an element declaration, and it can either be required or optional.

An element can have any number of sub-elements. The XML Schema specifies which sub-elements and how many times a given sub-element can occur. Here’s an example:

4.   <TopLevel>

5.     <FirstLevel>

6.       <SecondLevel>

7.         <ThirdLevel name=”first”></ThirdLevel>

8.         <ThirdLevel name=”second”></ThirdLevel>

9.       </SecondLevel>

10.   </FirstLevel>

11. </TopLevel>

In the above example, the FirstLevel has an sub-element SecondLevel which in turn has two sub-elements, ThirdLevel, with different names. Each level is an element and its children are its sub-elements and so forth.

In XML we sometimes use elements to organize parts of the document. A few examples in MTConnect® are StreamsDataItems, and Components. These elements have no attributes or data of their own; they only provide structure to the document and allow for various parts to be addressed easily.

1.   

2.   <Device id=”d” name=”Device”>

3.     <DataItems>

4.       <DataItem …/>

5.       …

6.     </DataItems>

7.     <Components>

8.       <Axes … >…</Axes>

9.     </Components>

10. </Device>

In the previous example DataItems and Components are only used to contain certain types of elements and provide structure to the documents. These elements will be referred to asContainters in the standard.

 An XML Document can be validated. The most basic check is to make sure it is well-formed, meaning that each element has a closing tag, as in <foo>...</foo> and the document does not contain any illegal characters (<>) when not specifying a tag. If the closing </foo> was left off or an extra > was in the document, the document would not be well-formed and may be rejected by the receiver. The document can also be validated against a schema to ensure it is valid. This second level of analysis checks to make sure that required elements and attributes are present and only occur the correct number of times. A valid document must be well-formed.

All MTConnect® documents must be valid and conform to the XML Schema provided along with this specification. The schema will be versioned along with this specification. The greatest possible care will be taken to make sure that the schema is backward compatible.

For more information, visit the w3c website for the XML Standards documentation: http://www.w3.org/XML/

2.3        Markup Conventions

MTConnect® follows industry conventions on tag format and notations when developing the XML schema. The general guidelines are as follows:

1.     All tag names will be specified in Pascal case (first letter of each word is capitalized). For example: <ComponentEvents />

2.     Attribute names will also be camel case, similar to Pascal case, but the first letter will be lower case. For example: <MyElement attributeName=”bob”/>

3.     All values that are part of a limited or controlled vocabulary will be in upper case with an _ (underscore) separating words. For example: ONOFFACTUAL, COUNTER_CLOCKWISE, etc…

4.     Dates and times will follow the W3C ISO 8601 format with arbitrary decimal fractions of a second allowed. Refer to the following specification for details: http://www.w3.org/TR/NOTE-datetime The format will be YYYY-MM-DDThh:mm:ss.ffff, for example 2007-09-13T13:01.213415. The accuracy and number of decimal fractional digits of the timestamp is determined by the capabilities of the device collecting the data. All times will be given in UTC (GMT).

5.     XML element names will be spelled-out and abbreviations will be avoided. The one exception is the word identifier that will be abbreviated Id. For example: SequenceNumberwill be used instead of SeqNum.

2.4        Document Conventions

The following documentation conventions will be used in the text:

   The word MUST is used to indicate provisions that are mandatory. Any deviation from those provisions will not be permitted.

   The word SHOULD is used to indicate a provision that is recommended but the exclusion of which will not invalidate the implementation.

   The word MAY will be used to indicate provisions that are optional and are up to the implementer to decide if they are relevant to their device.

   The word NOT will be added to any of the previous words to emphasize the negation of this provision.

In the tables where elements are described, the Occurrence column indicates if the attribute or sub-elements are required by the specification.

For attributes:

1.     If the Occurrence is 1, the attribute MUST be provided.

2.     If the Occurrence is 0..1, the attribute MAY be provided, and at most one occurrence of the attribute may be given.

2.

For XML elements:

1.     If the Occurrence is 1, the element MUST be provided.

2.     If the Occurrence is 0..1, the XML element MAY be provided, and at most one occurrence of the XML element may be given.

3.     If the Occurrence is 1..INF, one or more XML elements MUST be provided.

4.     If the Occurrence is a number, e.g. 2, exactly that number of XML elements MUST be provided.

2.5        Document Style Guidelines

The following conventions will be used throughout the document to provide a clear and consistent understanding of the use of each type of data and information used to define the MTConnect standard and associated data.

The following conventions will be used:

1.     Standard Font for text must be Times New Roman, unless noted otherwise.

2.     References to other Documents or Sections or Sub-Sections of this document must be italicized.

3.     Code samples will always be provided in fixed size Courier New font with line numbers as in:

1. <MTConnectStreams xmlns:m="urn:mtconnect.com:MTConnectStreams:1.1"

2.      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

3.      xmlns="urn:mtconnect.com:MTConnectStreams:1.1"    

4.   


4.     When MTConnect elements and functions are used where they represent a specific capability defined in the MTConnect standard, they will use fixed size Courier New font.   (Agent,probecurrent, etc.)   When these same items are generally referred to within the text without specific reference to their function within MTConnect, they will use standard font.

5.     All attribute values that are restricted to a limited or controlled vocabulary will be in upper case with an _ (underscore) separating words. For example: ONOFFACTUAL, COUNTER_CLOCKWISE, etc…  Font will be Courier New.

6.     All attribute names will be in Courier New font. For example: nativeUnits.

7.     When special emphasis is required on a word or words to differentiate them for other words and to provide additional clarity to the meaning of the standard, these words may be italicized orbolded (depending on the context of the surrounding text) to provide emphasis. Use of CAPS should be avoided for the purpose of providing emphasis.

2.6        Units

MTConnect® will adopt the units common to most standards specifications for exchanging data items. These units have been selected by the working group as giving the greatest interoperability and common acceptance.

Please see Part 2, Components and Data Items for a full description of allowable units and their associate data items.

2.7        Referenced Standards and Specifications

A large number of specifications are being used to normalize and harmonize the schema and the vocabulary (names of tags and attributes) specified in MTConnect® (See Appendix A: Bibliography for complete references).

3       Architectural Overview

MTConnect® is built upon the most prevalent standards in the industry. This maximizes the number of tools available for implementation and provides the highest level of interoperability with other standards and protocols.

MTConnect® MUST use the HTTP protocol as the underlying transport for all messaging. The data MUST be sent back in valid XML, according to this standard. Each MTConnect® Agent MUSTrepresent at least one device. The Agent MAY represent more than one device if desired.

MTConnect® is composed of a few basic conceptual parts. They are as follows:

Header           Protocol related information. (See Header in Part 1 Section 4)

Components The building blocks of the device. (See Components in Part 2 Section 3)

DataItems      The description of the data available from the device. (See DataItems in Part 2 Section 4 )

Streams         A set of Samples, Events, or Conditon for components and devices. (See Streams in Part 3)

Assets             An Asset is something that is associated with the manufacturing process that is not a component of a device, can be removed without detriment to the function of the device, and can be associated with other devices during their lifecycle.

Samples         A point-in-time measurement of a data item that is continuously changing. (See Samples in Part 3)

Events             Discrete changes in state that can have no intermediate value. They indicate the state of a specific attribute of a component. (See Events in Part 3)

Condition      A piece of information the device provides as an indicator of its health and ability to function. A condition can be one of NormalWarningFault, or Unavailable. A single condition type can have multiple Faults or Warnings at any given time. This behavior is different from Events and Samples where a data item MUST only have a single value at a given time. (See Condition in Part 3).

 

3.1        Request Structure

An MTConnect® request SHOULD NOT include any body in the HTTP request. If the Agent receives any additional data, the Agent MAY ignore it. There will be no cookies or additional information considered; the only information the Agent MUST consider is the URI in the HTTP GET (Type a URI into the browser’s address bar, hit return, and a GET is sent to the server. In fact, with MTConnect® one can do just that. To test the Agent, one can type the Agent’s URI into the browser’s address bar and view the results.)

3.2        Process Workflow

What follows is the typical interaction between four entities in the MTConnect® architecture: the Name Service (an LDAP server that translates device names to the Agent’s URI), the Application(a user application that makes special use of the device’s data), the Agent (the process collecting data from the device and delivering it to the applications), and the Device (the physical piece of equipment).

Note: Refer to Appendix B for more information on LDAP and the requirements for its use.

3.2.1    Agent Initialization

For this example, the agent first authenticates itself with the Name Server (if used). In the second part of the example, it shows how the entities interrelate in an architecture.


Figure 1: Agent Initialization

The diagram above illustrates the initialization of the Agent and communication with the device “mill”. Implementors Note: This is the recommended architecture and implementations SHOULDrefer to this when developing their MTConnect® Agents.

Step 1                   The Agent connects and authenticates itself with the Name Service (LDAP server).

Step 2                   The Agent registers its URI with the Name Service so it can be located.

Step 3                   The Agent connects to the Device using the device’s API or another specialized process.

Step 4                   The device sends data to the Agent or the Agent polls the device for data.

3.2.2    Application Communication

 Figure 2: Application Communication


The preceding diagram shows how all major components of an MTConnect® architecture inter-relate and how the four basic operations are used to locate and communicate with the Agent regarding the device.

Step 1                   The device is continually sending information to the Agent. The Agent is collecting the information and saving it based on its ability to store information. The data flow from the device to the agent is implementation dependant. The data flow can begin once a request has been issued from a client application at the discretion of the agent.

Step 2                   The Application locates the device using the Name Service with the standard LDAP syntax that is interpreted as follows: the mill is in the organizational unit of Equip which is in the example.com domain. The LDAP record for this device will contain a URI that the Application can use to contact the Agent.

Step 3                   The Application has the URI to contact the Agent for the mill device. The first step is a request for the device’s descriptive information using the probe request. The probe will return the component composition of the device as well as all the data items available.

Step 4                   The Application requests the current state for the device. The results will contain the device stream and all the component streams for this device. Each of the data items will report their values as Samples, Events or Condition. The application will receive the nextSequence number from the Agent to use in the subsequent sample request.

Step 5                   The Application uses the nextSequence number to sample the data from the Agent starting at sequence number 208. The results will be Events, Condition, and Samples; and since the count is not specified, it defaults to 100 Events, Samples, and Conditions.

This will be discussed in more detail in the Protocol section of the document. The remainder of this document will assume the Name Service discovery has already been completed.

3.3      MTConnect Agent Data Storage

The MTConnect Agent stores a fixed amount of data. This makes the process remain at a fixed maximum size since it is only required to store a finite number of events, samples and conditions. The data storage for MTConnect can be thought of as a tube where data is pushed in one end.


When the tube fills up, the oldest piece of data falls out the other end. In this example, the capacity, or bufferSize, of the MTConnect Agent in this example is 8.


As each piece of data is inserted into the tube it is assigned a sequentially increasing number.


As a client requests data from the MTConnect Agent it can specify the sequence number from which it will start returning data and the number of items to inspect. In the example below, the request starts at 15 (from) and requests three items (count). This will set the next sequence number (nextSequence) to 18 and the last sequence number will always be the last number in the tube. In this example it (lastSequence) is 19.


If the request goes off the end of the tube, the next sequence is set to the lastSequence + 1. As long as no more data is added to the Agent and the request exceeds the length of the data available, the nextSequence will remain the same, in this case 20.


The current request MUST provide the last value for each data item even if it is no longer in the buffer. Even if the event, sample, or condition has been removed from the buffer, the AgentMUST retain a copy associated with the last value for any subsequent current request. Therefor if the item 11 above was the last value for the X Position, the current will still provide the value of 11 when requested.

3.4      MTConnect Agent Asset Storage

MTConnect stores assets in a similar fashion. The Agent provides a limited number of assets that can be stored at one time and uses the same method of pushing out the oldest asset when the buffer is full. The buffer size for the asset storage is maintained separately from the sample, event, and condition storage.


Assets also behave like a key/value in memory database. In the case of the asset the key is the assetId and the value is the XML describing the asset. The key can be any string of letters, punctuation or digits and represent the domain specific coding scheme for their assets. Each asset type will have a recommended way to construct a unique assetId, for example, a Cutting ToolSHOULD be identified by the tool ID and serial number as a composed synthetic identifier.


As in this example, each of the assets is referred to by their key. The key is independent of the order in the storage buffer.

Asset protocol:

·      Request an asset by id:

o   url: http://example.com/asset/hh1

o   Returns the MTConnectAssets document for asset hh1

·      Request multiple assets by id:

o   url: http://example.com/asset/hh1;cc;123;g5

o   Returns the MTConnectAssets document for asset hh1, cc, 123, and g5.

·      Request for all the assets in the Agent:

o   url: http://example.com/assets

o   Returns all available MTConnect assets in the Agent. MTConnect MAY return a limited set if there are too many asset records. The assets MUST be added to the beginning with the most recently modified assets.

·      Request for all assets of a given type in the Agent:

o   url: http://example.com/assets?type=”CuttingTool”

o   Returns all available CuttingTool assets  from the  MTConnect Agent. MTConnect MAY return a limited set if there are too many asset records. The assets MUST be added to the beginning with the most recently modified assets.

When an asset is added or modified, an AssetChanged event will be sent to inform us that new asset data is available. The application can request the new asset data from the device at that time. Every time the asset data is modified the AssetChanged event will be sent. Since the asset data is transactional, meaning multiple values change at the same time, the system will send out a single AssetChanged event for the entire set of changes, not for the individual changed fields.

The tool data MUST remain constant until the AssetChanged event is sent. Once it is sent the data MUST change to reflect the new content at that instant. The timestamp of the asset will reflect the time the last change was made to the asset data.

Every time an asset is modified or added it will be moved to the end of the buffer and become the newest asset. As the buffer fills up, the oldest asset will be pushed out and its information will be removed. MTConnect does not specify the maximum size of the buffer, and if the implementation desires, permanent storage MAY be used to store the assets. A value of 4,294,967,296 or 232can be given to indicate unlimited storage.

There is no requirement for persistent asset storage. If the Agent fails, all existing assets MAY be lost. It is the responsibility of the implementation to restore the lost asset data and it is the responsibility of the application to persist the asset data. The MTConnect agent MAY make no guarantees about availability of asset data after the Agent stops.

4       Reply XML Document Structure

At the top level of all MTConnect® XML Documents there MUST be one of the following XML elements: MTConnectDevicesMTConnectStreams, or MTConnectError. This element will be the root for all MTConnect® responses and contains all sub-elements for the protocol.

All MTConnect® XML Documents are broken down into two parts. The first XML element is the Header that provides protocol related information like next sequence number and creation date and the second section provides the content for DevicesStreams, or Errors.

The top level XML elements MUST contain references to the XML schema URN and the schema location. These are the standard XML schema attributes:

1.   <MTConnectStreams xmlns:m="urn:mtconnect.com:MTConnectStreams:1.1"

2.      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

3.      xmlns="urn:mtconnect.com:MTConnectStreams:1.1"

4.      xsi:schemaLocation="urn:mtconnect.com:MTConnectStreams:1.1 http://www.mtconnect.org/schemas/MTConnectStreams.xsd"> …

4.1  MTConnectDevices


Figure 3: MTConnectDevices structure

MTConnectDevices provides the descriptive information about each device served by this Agent and specifies the data items that are available. In an MTConnectDevices XML Document, there MUST be a Header and  it MUST be followed by Devices section. An MTConnectDevices XML Document MUST have the following structure (the details have been eliminated for illustrative purposes):

5.   <MTConnectDevices xmlns:m="urn:mtconnect.com:MTConnectDevices:1.1"

6.      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

7.      xmlns="urn:mtconnect.com:MTConnectDevices:1.1"    

8.      xsi:schemaLocation="urn:mtconnect.com:MTConnectDevices:1.1 
          http://www.mtconnect.org/schemas/
MTConnectDevices_1.1.xsd">

9.     <Header …/>

10.   <Devices> … </Devices>

11. </MTConnectDevices>


4.1.1    MTConnectDevices Elements

An MTConnectDevices element MUST include the Header for all documents and the Devices element.

Element

Description

Occurrence

Header

A simple header with next sequence and creation time

1

Devices

The root of the descriptive data

1



For the above elements of the XML Document, please refer to Part 1 Section 4.5 Header and Part 2 Section 3 Devices and Components.

4.2   MTConnectStreams


Figure 4: MTConnectStreams structure

MTConnectStreams contains a timeseries of Samples, Events, and Condition from devices and their components. In an MTConnectStreams XML Document, there MUST be a Headerand  it MUST be followed by a Streams section. An MTConnectStreams XML Document will have the following structure (the details have been eliminated for illustrative purposes):

12. <MTConnectStreams xmlns:m="urn:mtconnect.com:MTConnectStreams:1.1"

13.    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

14.    xmlns="urn:mtconnect.com:MTConnectStreams:1.1"    

15.    xsi:schemaLocation="urn:mtconnect.com:MTConnectStreams:1.1 http://www.mtconnect.org/schemas/MTConnectStreams.xsd">

16.   <Header … />

17.   <Streams> … </Streams>

18. </MTConnectStreams>


4.2.1    MTConnectStreams Elements

An MTConnectStreams document MUST include a Header and a Streams element.

Element

Description

Occurrence

Header

A simple header with next sequence and creation time

1

Streams

The root of the sample and event data

1



For the above elements of the XML Document, please refer to Part 1 Section 4.5 Header and Part 3 Section 3.1 Streams Response Header and Part 3 Section 3.2 Streams Structure.

4.3   MTConnectAssets


Figure 5: MTConnectAssets structure

An MTConnect asset document contains information pertaining to a machine tool asset, something that is not a direct component of the machine and can be relocated to another device during its lifecycle. The Asset will contain transactional data that will be changed as a unit, meaning that at any point in time the latest version of the complete state for this asset will be given by this device.

Each device may have a different set of information about this asset and it is the responsibility of the application to collect and determine the best data and keep histories if necessary. MTConnect will allow any application or other device request this information. MTConnect makes no guarantees that this will be the best information across the entire set of devices, only that from this devices perspective, it is the latest and most accurate information it has supplied.

MTConnect allows any application to request information about an asset by its assetId. This identifier MUST be unique for all assets. The uniqueness is defined within the domain used by the implementation, meaning, if MTConnect will be used within a shop, the assetId MUST be unique within that shop. And conversely, if MTConnect will be used throughout an enterprise, it is advisable to make the assetId unique throughout the enterprise.

1.   <?xml version="1.0" encoding="UTF-8"?>

2.   <MTConnectAssets xsi:schemaLocation="urn:mtconnect.org:MTConnectAssets:1.2 ../MTConnectAssets_1.2.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:mtconnect.org:MTConnectAssets:1.2" xmlns:mt="urn:mtconnect.org:MTConnectAssets:1.2">

3.         <Header creationTime="2001-12-17T09:30:47Z" sender="localhost" version="1.2" bufferSize="131000" instanceId="1" />

4.         <Assets>

5.               <CuttingTool serialNumber="1234" timestamp="2001-12-17T09:30:47Z" assetId="1234-112233">

6.                     <Description>Cutting Tool</Description>

7.                     <ToolDefinition>…</ToolDefinition>

8.                     <ToolLifeCycle deviceUuid="1222" toolId="1234">…

9.                     </ToolLifeCycle>

10.             </CuttingTool>

11.       </Assets>

12. </MTConnectAssets>

The document is broken down into two sections, the tool definition (line 7) and the tool life cycle (lines 8-9). For more information on this structure, see Part 4: Assets.

4.4   MTConnectError


Figure 6: MTConnectError structure

An MTConnectError document contains information about an error that occurred in processing the request. In an MTConnectError XML Document, there MUST be a Header and it must be followed by an Errors container that can contain a series of Error elements:

1.  <?xml version="1.0" encoding="UTF-8"?>

2.  <MTConnectError xmlns="urn:mtconnect.org:MTConnectError:1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="urn:mtconnect.org:MTConnectError:1.1 http://www.mtconnect.org/schemas/MTConnectError_1.1.xsd">

3.    <Header creationTime="2010-03-12T12:33:01" sender="localhost" version="1.1" bufferSize="131072" instanceId="1268463594" />

4.    <Errors>

5.      <Error errorCode="OUT_OF_RANGE" >Argument was out of range</Error>

6.      <Error errorCode="INVALID_XPATH" >Bad path</Error>

7.    </Errors>

8.  </MTConnectError>


For purposes of backward compatibility, a single error can have a single Error element.

1.  <?xml version="1.0" encoding="UTF-8"?>

2.  <MTConnectError xmlns="urn:mtconnect.org:MTConnectError:1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="urn:mtconnect.org:MTConnectError:1.1 http://www.mtconnect.org/schemas/MTConnectError_1.1.xsd">

3.    <Header creationTime="2010-03-12T12:33:01" sender="localhost" version="1.1" bufferSize="131072" instanceId="1268463594" />

4.    <Error errorCode="OUT_OF_RANGE" >Argument was out of range</Error>

5.  </MTConnectError>

4.4.1    MTConnectError Elements

An MTConnect® document MUST include the Header for all documents and one Error element.

Element

Description

Occurrence

Header

A simple header with next sequence and creation time

1

Errors

A collection of Error elements.

1



For the above elements of the XML Document, please refer to section 4.5 for Header and section 5.6 for Error.

4.5        Header

Every MTConnect® response MUST contain a header as the first element below the root element of any MTConnect® XML Document sent back to an application. The following informationMUST be provided in the header: creationTimeinstanceIdsenderbufferSize, and version. If the document is an MTConnectStreams document it MUST also contain thenextSequencefirstSequence, and lastSequence attributes as well.

4.6      MTConnectDevices Header


4.6.1    Header attributes:

See below for full description of common attributes

4.6.2      Header Elements

Element

Description

Occurrence

AssetCount

Contains the number of each asset type currently in the agent. This allows applications to determine the present of assets of a certain type. The CDATA of this MUST be an integer value representing the count. It MUST be less than or equal to the maximum number of assets (assetBufferSize).

0..1

4.6.3    AssetCount attributes:

Attribute

Description

Occurrence

assetType

The type of assets for the count.

1


4.7      MTConnectStreams Header

The second header is for MTConnectStreams where the protocol sequence information MUST be provided:


Figure 7: Header Schema Diagram for MTConnectStreams


<Header creationTime="2010-03-13T07:59:11+00:00" sender="localhost" 
        instanceId
="1268463594" bufferSize="131072" version="1.1"
 
       nextSequence="154" firstSequence="1" lastSequence="153" />

4.8      MTConnectAssets Header

The second header is for MTConnectAssets where the protocol sequence information MUST be provided:


Figure 8: Header Schema Diagram for MTConnectAssets


<Header creationTime="2010-03-13T07:59:11+00:00" sender="localhost" 
        instanceId
="1268463594" assetBufferSize="1024" version="1.1"
 
       assetCount="12" />

4.9      MTConnectError Header

The MTConnectError header is as follows:


Figure 9: Header Schema Diagram for MTConnectError

4.10  All Header Attributes

Attribute

Description

Occurrence

creationTime

The time the response was created.

1

nextSequence

The sequence number to use for the next request. Used for sample and current requests. Not used in probe request. This value MUST have a maximum value of 2^64-1 and MUST be stored in a signed 64 bit integer.

0..1

instanceId

A number indicating which invocation of the Agent. This is used to differentiate between separate instances of the Agent. This value MUST have a maximum value of 2^64-1 and MUST be stored in a unsigned 64 bit integer.

1

testIndicator

Optional flag that indicates the system is operating in test mode. This data is only for testing and indicates that the data is simulated.

0..1

sender

The Agent identification information.

1

bufferSize

The number of Samples, Events, and Condition that will be retained by the Agent. The buffersize MUST be an unsigned positive integer value with a maximum value of 2^32-1.

1

firstSequence

The sequence number of the first sample or event available. This value MUST have a maximum value of 2^64-1 and MUST be stored in an unsigned 64 bit integer.

0..1

lastSequence

The sequence number of the last sample or event available. This value MUST have a maximum value of 2^64-1 and MUST be stored in an unsigned 64 bit integer.

0..1

version

The protocol version number. This is the major and minor version number of the MTConnect standard being used. For example if the version number is current10.21.33,  the version will be 10.21.

1

assetBufferSize

The maximum number of assets this agent can store.MUST be an unsigned positive integer value with a maximum value of 2^32-1.

1

assetCount

The total number of assets in the agent. MUST be an unsigned positive integer value with a maximum value of 2^32-1. This value MUST not be greater thanassetBufferSize

1


The nextSequencefirstSequence, and lastSequence number MUST be included in sample and current responses. These values MAY be used by the client application to determine if the sequence values are within range.The testIndicator MAY be provided as needed.

Details on the meaning of various fields and how they relate to the protocol are described in detail in the next section on Section 5 - Protocol. The standard specifies how the protocol MUST be implemented to provide consistent MTConnect® Agent behavior.

The instanceId MAY be implemented using any unique information that will be guaranteed to be different each time the sequence number counter is reset. This will usually happen when the MTConnect® Agent is restarted. If the Agent is implemented with the ability to recover the event stream and the next sequence number when it is restarted, then it MUST use the sameinstanceId when it restarts.

The instanceId allows the MTConnect® Agents to forgo persistence of Events, Condition, and Samples and restart clean each time. Persistence is a decision for each implementation to be determined. This will be discussed further in the section on Section 5.11 - Fault Tolerance and Recovery.

The sender MUST be included in the header to indicate the identity of the Agent sending the response. The sender MUST be in the following format: http://<address>[:port]/. Theport MUST only be specified if it is NOT the default HTTP port 80.

 The bufferSize MUST contain the maximum number of results that can be stored in the Agent at any one instant. This number can be used by the application to determine how frequently it needs to sample and if it can recover in case of failure. It is the decision of the implementer to determine how large the buffer should be.

As a general rule, the buffer SHOULD be sufficiently large to contain at least five minutes’ worth of Events, Condition, and Samples. Larger buffers are more desirable since they allow longer application recovery cycles. If the buffer is too small, data can be lost. The Agent SHOULD NOT be designed so it becomes burdensome to the device and could cause any interruption to normal operation.

5       Protocol

The MTConnect® Agent collects and distributes data from the components of a device to other devices and applications. The standard requires that the protocol MUST function as described in this section; the tools used to implement the protocol are the decision of the developer.

MTConnect® provides a RESTful interface. The term REST is short for REpresentational State Transfer and provides an architectural framework that defines how state will be managed within the application and Agent. REST dictates that the server is unaware of the clients state and it is the responsibility of the client application to maintain the current read position or next operation. This removes the server’s burden of keeping track of client sessions. The underlying protocol is HTTP, the same protocol as used in all web browsers.

The MTConnect® Agent MUST support HTTP version 1.0 or greater. The only requirement for an MTConnect® Agent is that it MUST support the HTTP GET verb. The response to an MTConnect® request MUST always be in XML. The HTTP request SHOULD NOT include a body. If the Agent receives a body, the Agent MAY ignore it. The Agent MAY ignore any cookies or additional information. The only information the Agent MUST consider is the URI in the HTTP GET.

If the HTTP GET verb is not used, the Agent must respond with a HTTP 400 Bad Request indicating that the client issued a bad request. See Section 5.7 HTTP Response Code and Error for further discussion on error handling.

The reference implementation of MTConnect is based on the use of XML and HTTP. MTConnect MAY also be implemented in conjunction with other technologies and standards. In its reference implementation, MTConnect MUST follow the conventions defined in Part 1- Section 5 of the MTConnect standard. When implemented using other technologies or standards, a companion specification MUST be developed and exemptions to the requirements in Section 5 MUST be defined in the companion specification.

5.1        Standard Request Sequence

MTConnect® Agent MUST support three types of requests:

   probe – to retrieve the components and the data items for the device. Returns a MTConnectDevices XML document.

   current – to retrieve a snapshot of the data item’s most recent values or the state of the device at a point in time. Returns an MTConnectStreams XML document.

   sample – to retrieve the Samples, Events, and Condition in time series. Returns an MTConnectStreams XML document.

   asset – to request the most recent state of an asset known to this device.

The sequence of requests for a standard MTConnect® conversation will typically begin with the application issuing a probe to determine the capabilities of the device. The result of the probewill provide the component structure of the device and all the available data items for each component.

Once the application determines the necessary data items are available from the Agent, it can issue a current request to acquire the latest values of all the data items and the next sequence number for subsequent sample requests. The application SHOULD also record the instanceId to know when to reset the sequence number in the eventuality of Agent failure. (See Section 5.11 Fault Tolerance for a complete discussion of the use of instanceId).

Once the current state has been retrieved, the Agent can be sampled at a rate determined by the needs of the application. After each request, the application SHOULD save the nextSequencenumber for the next request. This allows the application to receive all results without missing a single sample or event and removes the need for the application to compute the value of the fromparameter for the next request.


Figure 10: Application and Agent Conversation


The above diagram illustrates a standard conversation between an application and an MTConnect® Agent. The sequence is very simple because the entire protocol is an HTTP request/response. The next sequence number handling is shown as a guideline for capturing the stream of Samples, Events, and Condition.

While the above diagram illustrates a standard conversation between an application and an MTConnect® Agent, any one application or multiple applications may be having several unrelated standard conversations occurring simultaneously with the MTConnect® Agent, each potentially referencing different data or data types and using different portions of the Agent's data table.

5.2        Probe Requests

The MTConnect® Agent MUST provide a probe response that describes this Agent’s devices and all the devices’ components and data items being collected. The response to the probe MUSTalways provide the most recent information available. A probe request MUST NOT supply any parameters. If any are supplied, they MUST be ignored. The response from the probe will be static as long as the machine physical composition and capabilities do not change, therefore it is acceptable to probe very infrequently. In many cases, once a week may be sufficient.

The probe request MUST support two variations:

   The first provides information on only one device. The device’s name MUST be specified in the first part of the path. This example will only retrieve components and data items for the mill-1 device.

13. http://10.0.1.23/mill-1/probe

   The second does not specify the device and therefore retrieves information for all devices:

14. http://10.0.1.23/probe

5.2.1.1    Example

The following is an example probe response for 4 Axis Simulator:

1.   <?xml version="1.0" encoding="UTF-8"?>

2.   <MTConnectDevices xmlns:m="urn:mtconnect.org:MTConnectDevices:1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns="urn:mtconnect.org:MTConnectDevices:1.1" xsi:schemaLocation="urn:mtconnect.org:MTConnectDevices:1.1 http://www.mtconnect.org/schemas/MTConnectDevices_1.1.xsd">

3.    <Header creationTime="2010-03-13T08:02:38+00:00" sender="localhost" instanceId="1268463594" bufferSize="131072" version="1.1" />

4.    <Devices>

5.     <Device id="dev" name="VMC-4Axis" uuid="XXX111">

6.      <DataItems>

7.       <DataItem category="EVENT" id="avail" type="AVAILABILITY" />

8.      </DataItems>

9.      <Components>

10.     <Axes id="axes" name="axes">

11.      <Components>

12.       <Linear id="x" name="X">

13.        <DataItems>

14.         <DataItem category="SAMPLE" id="Xact" nativeUnits="MILLIMETER" subType="ACTUAL" type="POSITION" units="MILLIMETER" />

15.         <DataItem category="SAMPLE" id="Xload" nativeUnits="PERCENT" type="LOAD" units="PERCENT" />

16.         <DataItem category="CONDITION" id="Xtravel" type="POSITION" />

17.         <DataItem category="CONDITION" id="Xovertemp" type="TEMPERATURE" />

18.         <DataItem category="CONDITION" id="Xservo" type="ACTUATOR" />

19.        </DataItems>

20.       </Linear>

21.       <Linear id="y" name="Y">

22.        <DataItems>

23.         <DataItem category="SAMPLE" id="Yact" nativeUnits="MILLIMETER" subType="ACTUAL" type="POSITION" units="MILLIMETER" />

24.         <DataItem category="SAMPLE" id="Yload" nativeUnits="PERCENT" type="LOAD" units="PERCENT" />

25.         <DataItem category="CONDITION" id="Ytravel" type="POSITION" />

26.         <DataItem category="CONDITION" id="Yovertemp" type="TEMPERATURE" />

27.         <DataItem category="CONDITION" id="Yservo" type="ACTUATOR" />

28.        </DataItems>

29.       </Linear>

30.       <Linear id="z" name="Z">

31.        <DataItems>

32.         <DataItem category="SAMPLE" id="Zact" nativeUnits="MILLIMETER" subType="ACTUAL" type="POSITION" units="MILLIMETER" />

33.         <DataItem category="SAMPLE" id="Zload" nativeUnits="PERCENT" type="LOAD" units="PERCENT" />

34.         <DataItem category="CONDITION" id="Ztravel" type="POSITION" />

35.         <DataItem category="CONDITION" id="Zovertemp" type="TEMPERATURE" />

36.         <DataItem category="CONDITION" id="Zservo" type="ACTUATOR" />

37.        </DataItems>

38.       </Linear>

39.       <Rotary id="a" name="A">

40.        <DataItems>

41.         <DataItem category="SAMPLE" id="Aact" nativeUnits="DEGREE" subType="ACTUAL" type="ANGLE" units="DEGREE" />

42.         <DataItem category="SAMPLE" id="Aload" nativeUnits="PERCENT" type="LOAD" units="PERCENT" />

43.         <DataItem category="CONDITION" id="Atravel" type="POSITION" />

44.         <DataItem category="CONDITION" id="Aovertemp" type="TEMPERATURE" />

45.         <DataItem category="CONDITION" id="Aservo" type="ACTUATOR" />

46.        </DataItems>

47.       </Rotary>

48.       <Rotary id="c" name="C" nativeName="S1">

49.        <DataItems>

50.         <DataItem category="SAMPLE" id="S1speed" nativeUnits="REVOLUTION/MINUTE" type="SPINDLE_SPEED" units="REVOLUTION/MINUTE" />

51.         <DataItem category="EVENT" id="S1mode" type="ROTARY_MODE">

52.          <Constraints>

53.           <Value>SPINDLE</Value>

54.          </Constraints>

55.         </DataItem>

56.         <DataItem category="SAMPLE" id="S1load" nativeUnits="PERCENT" type="LOAD" units="PERCENT" />

57.         <DataItem category="CONDITION" id="spindle" type="SYSTEM" />

58.        </DataItems>

59.       </Rotary>

60.      </Components>

61.     </Axes>

62.     <Controller id="cont" name="controller">

63.      <DataItems>

64.       <DataItem category="CONDITION" id="logic" type="LOGIC_PROGRAM" />

65.       <DataItem category="EVENT" id="estop" type="EMERGENCY_STOP" />

66.       <DataItem category="CONDITION" id="servo" type="ACTUATOR" />

67.       <DataItem category="EVENT" id="message" type="MESSAGE" />

68.       <DataItem category="CONDITION" id="comms" type="COMMUNICATIONS" />

69.      </DataItems>

70.      <Components>

71.       <Path id="path" name="path">

72.        <DataItems>

73.         <DataItem category="SAMPLE" id="SspeedOvr" nativeUnits="PERCENT" subType="OVERRIDE" type="SPINDLE_SPEED" units="PERCENT" />

74.         <DataItem category="EVENT" id="block" type="BLOCK" />

75.         <DataItem category="EVENT" id="execution" type="EXECUTION" />

76.         <DataItem category="EVENT" id="program" type="PROGRAM" />

77.         <DataItem category="SAMPLE" id="path_feedrate" nativeUnits="MILLIMETER/SECOND" type="PATH_FEEDRATE" units="MILLIMETER/SECOND" />

78.         <DataItem category="EVENT" id="mode" type="CONTROLLER_MODE" />

79.         <DataItem category="EVENT" id="line" type="LINE" />

80.         <DataItem category="SAMPLE" id="path_pos" nativeUnits="MILLIMETER_3D" subType="ACTUAL" type="PATH_POSITION" units="MILLIMETER_3D" />

81.         <DataItem category="SAMPLE" id="probe" nativeUnits="MILLIMETER_3D" subType="PROBE" type="PATH_POSITION" units="MILLIMETER_3D" />

82.         <DataItem category="EVENT" id="part" type="PART_ID" />

83.         <DataItem category="CONDITION" id="motion" type="MOTION_PROGRAM" />

84.         <DataItem category="CONDITION" id="system" type="SYSTEM" />

85.        </DataItems>

86.       </Path>

87.      </Components>

88.     </Controller>

89.    </Components>

90.   </Device>

91.  </Devices>

92. </MTConnectDevices>

5.3        Sample Request

The sample request retrieves the values for the component’s data items. The response to a sample request MUST be a valid MTConnectStreams XML Document.

The diagram below is an example of all the components and data items in relation to one another. The device has one Controller with a single Path, three linear and one rotary axis. The Controller’s Path is capable of providing the execution status and the current block of code. The device has a DataItem with type=”AVAILABILITY”, that indicates the device is available to communicate.


 Figure 11: Sample Device Organization

The following path will request the data items for all components in mill-1 with regards to the example above (note that the path parameter refers to the XML Document structure from the probe request, not the XML Document structure of the sample):

15. http://10.0.1.23:3000/mill-1/sample

This is equivalent to providing a path-based filter for the device named mill-1:

16. http://10.0.1.23:3000/sample?path=//Device[@name=”mill-1”]

To request all the axes’ data items the following path expression is used:

17. http://10.0.1.23:3000/mill-1/sample?path=//Axes

To specify only certain data items to be included (e.g. the positions from the axes), use this form:

18. http://10.0.1.23:3000/mill-1/sample?path=//Axes//DataItem[@type=”POSITION”]

To retrieve only actual positions instead of both the actual and commanded, the following path syntax can be used:

19. http://10.0.1.23:3000/mill-1/sample?path=//Axes//DataItem[@type=”POSITION” and @subType=”ACTUAL”]

or:

20. http://10.0.1.23:3000/mill-1/sample?path=//Axes//DataItem[@type=”POSITION” and @subType=”ACTUAL”]&from=50&count=100

The above example will retrieve all the axes’ positions from sample 50 to sample 150. The actual number of items returned will depend on the contents of the data in the Agent and the number of results that are actual position samples.

A more complete discussion of the protocol can be found in the section on Protocol Details – Part 1, Section 5.8.

5.3.1    Parameters

All parameters MUST only be given once and the order of the parameters is not important. The MTConnect® Agent MUST accept the following parameters for the sample request:

path - This is an xpath expression specifying the components and/or data items to include in the sample. If the path specifies a component, all data items for that component and any of its sub-components MUST be included. For example, if the application specifies the path=//Axes, then all the data items for the Axes component as well as the Linear and Rotary sub-components MUST be included as well.

from - This parameter requests Events, Condition, and Samples starting at this sequence number. The sequence number can be obtained from a prior current or sample request.  The responseMUST provide the nextSequence number. If the value is 0 the first available sample or event MUST be used. If the value is less than 0 (< 0) an INVALID_REQUEST error MUST be returned.

count - The maximum number of Events, Condition, and Samples to consider, see detailed explanation below. Events, Condition, and Samples will be considered between from and from + count, where the latter is the lesser of from + count and the last sequence number stored in the agent. The Agent MUST NOT send back more than this number of Events, Condition, and Samples (in aggregate), but fewer Events, Condition, and Samples MAY be returned. If the value is less than 1 (< 1) an INVALID_REQUEST error MUST be returned.

interval – The Agent MUST stream Samples, Events, and Condition to the client application pausing for interval milliseconds between each part. Each part will contain a maximum ofcount Events, Samples, and Condition and from will be used to indicate the beginning of the stream.

The nextSequence number in the header MUST be set to the sequence number following the largest sequence number (highest sequence number + 1) of all the Events, Condition, and Samples considered when collecting the results.

If no parameters are given, the following defaults MUST be used:

The path MUST default to all components in the device or devices if no device is specified.

The count MUST default to 100 if it is not specified.

The from MUST default to 0 and return the first available event or sample. If the latest state is desired, see current.

5.4        Current Request

If specified without the at parameter, the current request retrieves the values for the components’ data items at the point the request is received and MUST contain the most current values for all data items specified in the request path. If the path is not given, it MUST respond with all data items for the device(s), in the same way as the sample request. The current MUST return the values for the data items, even if the data items are no longer in the buffer.

current MUST return the nextSequence number for the event or sample directly following the point at which the snapshot was taken. This MUST be determined by finding the sequence number of the last event or sample in the Agent and adding one (+1) to that value. The nextSequence number MAY be used for subsequent samples.

The Samples, Events, and Condition returned from the current request MUST have the time-stamp and the sequence number that was assigned at the time the data was collected. The AgentMUST NOT alter the original time, sequence, or values that were assigned when the data was collected.

http://10.0.1.23:3000/mill-1/current?path=//Axes//DataItem[@type=”POSITION” and @subType=”ACTUAL”]

This example will retrieve the current actual positions for all the axes, as with a sample, except with current, there will always be a sample or event for each data item if at least one piece of data was retrieved from the device.

http://10.0.1.23:3000/mill-1/current?path=//Axes//DataItem[@type=”POSITION” and @subType=”ACTUAL”]&at=1232

The above example retrieves the axis actual position at a specific earlier point in time - in this case, at Sequence Number 1232.

5.4.1    Parameters

The MTConnect® Agent MUST accept the following parameter for the current request:

path - same requirements as sample.

interval - same requirements as sampleMUST NOT be used with at.

at - an optional argument specifying the MTConnect protocol sequence number. If supplied, the most current values on or before the sequence number MUST be provided. If at is not provided, the latest values MUST be provided. at MUST NOT be used with the interval as this will just return the same data set repeatedly.

If no parameters are provided for the current request, all data items MUST be retrieved with their latest values.

5.4.2      Getting the State at a Sequence Number

The current at allows an application to monitor real-time conditions and then perform causal analysis by requesting the current values for all the data items at the sequence number of interest. This removes the requirement that the application continually poll for all states and burden the server and the network with unneeded information associated with faults or other abnormal conditions. Please refer to Part 1 - 5.8.1 Buffer Semantics for a full description of the behavior of the storage and retrieval of data when using the at parameter.

An example of the current request using the at parameter with a very simple machine configuration:

<?xml version="1.0" encoding="UTF-8"?>

<MTConnectDevices xmlns="urn:mtconnect.org:MTConnectDevices:1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="urn:mtconnect.org:MTConnectDevices:1.1 http://www.mtconnect.org/schemas/MTConnectDevices_1.1.xsd">

  <Header creationTime="2010-04-01T21:22:43" sender="host" version="1.1" bufferSize="1" instanceId="1"/>

  <Devices>

    <Device name="minimal" uuid="1" id="d">

      <DataItems>

        <DataItem type="AVAILABILITY" category="EVENT" id="avail" />

      </DataItems>

      <Components>

        <Controller name="controller" id="c1">

          <DataItems>

            <DataItem id="estop" type="EMERGENCY_STOP" category="EVENT"/>

            <DataItem id="system" type="SYSTEM" category="CONDITION" />

          </DataItems>

          <Components>

            <Path id="p1" name="path" >

              <DataItems>

                <DataItem id="execution" type="EXECUTION" category="EVENT"/>

              </DataItems>

            </Path>

          </Components>

         </Controller>

       </Components>

     </Device>

  </Devices>

</MTConnectDevices>

Here is a series of events and condition:

Time Offset

Sequence

Id

Value

06:19:25.089023

1

estop

UNAVAILABLE

06:19:25.089023

2

execution

UNAVAILABLE

06:19:25.089023

3

avail

UNAVAILABLE

06:19:25.089023

4

system

Unavailable

06:19:35.153141

5

avail

AVAILABLE

06:19:35.153141

6

execution

STOPPED

06:19:35.153141

7

estop

ACTIVE

06:19:35.153370

8

system

Normal

06:20:05.153230

9

estop

RESET

06:20:05.153230

10

execution

ACTIVE

06:20:35.153716

11

system

Fault

06:21:05.153587

12

execution

STOPPED

06:21:35.153784

13

system

Normal

06:22:05.153741

14

execution

ACTIVE


If a current request is made after this sequence of events, the result will be as follows:

<?xml version="1.0" encoding="UTF-8"?>

<MTConnectStreams xmlns:m="urn:mtconnect.org:MTConnectStreams:1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns="urn:mtconnect.org:MTConnectStreams:1.1" xsi:schemaLocation="urn:mtconnect.org:MTConnectStreams:1.1 http://www.mtconnect.org/schemas/MTConnectStreams_1.1.xsd">

  <Header creationTime="2010-04-06T06:53:34+00:00" sender="localhost" instanceId="1270534765" bufferSize="16" version="1.1" nextSequence="19"firstSequence="3" lastSequence="18" />

  <Streams>

    <DeviceStream name="minimal" uuid="1">

      <ComponentStream component="Device" name="minimal" componentId="d">

        <Events>

          <Availability dataItemId="avail" sequence="5" timestamp="2010-04-06T06:19:35.153141">AVAILABLE</Availability>

        </Events>

      </ComponentStream>

      <ComponentStream component="Controller" name="controller" componentId="c1">

        <Events>

          <EmergencyStop dataItemId="estop" sequence="9" timestamp="2010-04-06T06:20:05.153230">RESET</EmergencyStop>

        </Events>

        <Condition>

          <Normal dataItemId="system" sequence="13" timestamp="2010-04-06T06:21:35.153784" type="SYSTEM" />

        </Condition>

      </ComponentStream>

      <ComponentStream component="Path" name="path" componentId="p1">

        <Events>

          <Execution dataItemId="execution" sequence="14" timestamp="2010-04-06T06:22:05.153741">ACTIVE</Execution>

        </Events>

      </ComponentStream>

    </DeviceStream>

  </Streams>

</MTConnectStreams>


If we want to inspect the state of the machine  at the point the fault occurred, sequence number 11, we can issue a request: http://localhost:5000/current?at=11. This will return the following response:

<?xml version="1.0" encoding="UTF-8"?>

<MTConnectStreams xmlns:m="urn:mtconnect.org:MTConnectStreams:1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns="urn:mtconnect.org:MTConnectStreams:1.1" xsi:schemaLocation="urn:mtconnect.org:MTConnectStreams:1.1 http://www.mtconnect.org/schemas/MTConnectStreams_1.1.xsd">

  <Header creationTime="2010-04-06T07:05:49+00:00" sender="localhost" instanceId="1270534765" bufferSize="16" version="1.1" nextSequence="19"firstSequence="3" lastSequence="18" />

  <Streams>

    <DeviceStream name="minimal" uuid="1">

      <ComponentStream component="Device" name="minimal" componentId="d">

        <Events>

          <Availability dataItemId="avail" sequence="5" timestamp="2010-04-06T06:19:35.153141">AVAILABLE</Availability>

        </Events>

      </ComponentStream>

      <ComponentStream component="Controller" name="controller" componentId="c1">

        <Events>

          <EmergencyStop dataItemId="estop" sequence="9" timestamp="2010-04-06T06:20:05.153230">RESET</EmergencyStop>

        </Events>

        <Condition>

          <Fault dataItemId="system" sequence="11" timestamp="2010-04-06T06:20:35.153716" type="SYSTEM" />

        </Condition>

      </ComponentStream>

      <ComponentStream component="Path" name="path" componentId="p1">

        <Events>

          <Execution dataItemId="execution" sequence="10" timestamp="2010-04-06T06:20:05.153230">ACTIVE</Execution>

        </Events>

      </ComponentStream>

    </DeviceStream>

  </Streams>

</MTConnectStreams>


With MTConnect you can replay the history and move forward a single sequence to see what happened immediately after the fault occurred: http://localhost:5000/current?at=12.

<?xml version="1.0" encoding="UTF-8"?>

<MTConnectStreams xmlns:m="urn:mtconnect.org:MTConnectStreams:1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns="urn:mtconnect.org:MTConnectStreams:1.1" xsi:schemaLocation="urn:mtconnect.org:MTConnectStreams:1.1 http://www.mtconnect.org/schemas/MTConnectStreams_1.1.xsd">

  <Header creationTime="2010-04-06T07:05:55+00:00" sender="localhost" instanceId="1270534765" bufferSize="16" version="1.1" nextSequence="19"firstSequence="3" lastSequence="18" />

  <Streams>

    <DeviceStream name="minimal" uuid="1">

      <ComponentStream component="Device" name="minimal" componentId="d">

        <Events>

          <Availability dataItemId="avail" sequence="5" timestamp="2010-04-06T06:19:35.153141">AVAILABLE</Availability>

        </Events>

      </ComponentStream>

      <ComponentStream component="Controller" name="controller" componentId="c1">

        <Events>

          <EmergencyStop dataItemId="estop" sequence="9" timestamp="2010-04-06T06:20:05.153230">RESET</EmergencyStop>

        </Events>

        <Condition>

          <Fault dataItemId="system" sequence="11" timestamp="2010-04-06T06:20:35.153716" type="SYSTEM" />

        </Condition>

      </ComponentStream>

      <ComponentStream component="Path" name="path" componentId="p1">

        <Events>

          <Execution dataItemId="execution" sequence="12" timestamp="2010-04-06T06:21:05.153587">STOPPED</Execution>

        </Events>

      </ComponentStream>

    </DeviceStream>

  </Streams>

</MTConnectStreams>


Here one can see that execution state has now transitioned to STOPPED and the Fault is still active. The application is free to scroll through the buffer from the first sequence number to the last sequence number.

It should also be noted that the first sequence number is 3 and a request before this first sequence number is not allowed. If, for example, a request is made at sequence 2:http://localhost:5000/current?at=2, an error will be returned:

<?xml version="1.0" encoding="UTF-8"?>

<MTConnectError xmlns:m="urn:mtconnect.org:MTConnectError:1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns="urn:mtconnect.org:MTConnectError:1.1" xsi:schemaLocation="urn:mtconnect.org:MTConnectError:1.1 http://www.mtconnect.org/schemas/MTConnectError_1.1.xsd">

  <Header creationTime="2010-04-06T22:01:17+00:00" sender="localhost" instanceId="1270534765" bufferSize="16" version="1.1" />

  <Errors>

    <Error errorCode="QUERY_ERROR">'at' must be greater than or equal to 3.</Error>

  </Errors>

</MTConnectError>

5.4.3      Determining Event Duration

A common requirement is to determine the duration of an event, such as how long the machine has been actively executing a program. The addition of current with the at parameter facilitates this operation. The following is an example based on the value of the Execution tag.

<?xml version="1.0" encoding="UTF-8"?>

<MTConnectStreams xmlns:m="urn:mtconnect.org:MTConnectStreams:1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:mtconnect.org:MTConnectStreams:1.1"xsi:schemaLocation="urn:mtconnect.org:MTConnectStreams:1.1 http://www.mtconnect.org/schemas/MTConnectStreams_1.1.xsd">

  <Header creationTime="2010-04-17T08:05:10+00:00" sender="localhost" instanceId="1267747762" bufferSize="131072" version="1.1" nextSequence="746859061" firstSequence="746727989"lastSequence="746859060" />

  <Streams>

    <DeviceStream name="VMC-3Axis" uuid="000">

      <ComponentStream component="Path" name="path" componentId="pth">

        <Samples>

          <PathFeedrate dataItemId="Fovr" sequence="746803687" timestamp="2010-04-17T08:01:45.149887">100.0000000000</PathFeedrate>

          <PathFeedrate dataItemId="Frt" sequence="746859054" timestamp="2010-04-17T08:05:09.829551">0</PathFeedrate>

        </Samples>

        <Events>

          <Block dataItemId="cn2" name="block" sequence="746858893" timestamp="2010-04-17T08:05:08.597481">G0Z1</Block>

          <ControllerMode dataItemId="cn3" name="mode" sequence="746803685" timestamp="2010-04-17T08:01:45.149887">AUTOMATIC</ControllerMode>

          <Line dataItemId="cn4" name="line" sequence="746859056" timestamp="2010-04-17T08:05:09.861553">0</Line>

          <Program dataItemId="cn5" name="program" sequence="746803684" timestamp="2010-04-17T08:01:45.149887">FLANGE_CAM.NGC</Program>

          <Execution dataItemId="cn6" name="execution" sequence="746859059" timestamp="2010-04-17T08:05:09.905555">READY</Execution>

        </Events>                     

      </ComponentStream>

    </DeviceStream>

  </Streams>

</MTConnectStreams>

When the execution value changes to READY after it was in the ACTIVE state, we can determine the duration by performing a current with at set to one minus the sequence number of the event in question. In this case Execution has a sequence number 746859059, so one would perform a request as follows:

http://agent.mtconnect.org:5000/current?path=//Path&at=746859058

This will result in the following response:

<?xml version="1.0" encoding="UTF-8"?>

<MTConnectStreams xmlns:m="urn:mtconnect.org:MTConnectStreams:1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:mtconnect.org:MTConnectStreams:1.1"xsi:schemaLocation="urn:mtconnect.org:MTConnectStreams:1.1 http://www.mtconnect.org/schemas/MTConnectStreams_1.1.xsd">

  <Header creationTime="2010-04-17T08:05:33+00:00" sender="localhost" instanceId="1267747762" bufferSize="131072" version="1.1" nextSequence="746859061" firstSequence="746727989"lastSequence="746859060" />

  <Streams>

    <DeviceStream name="VMC-3Axis" uuid="000">

      <ComponentStream component="Path" name="path" componentId="pth">

        <Samples>

          <PathFeedrate dataItemId="Fovr" sequence="746803687" timestamp="2010-04-17T08:01:45.149887">100.0000000000</PathFeedrate>

          <PathFeedrate dataItemId="Frt" sequence="746859054" timestamp="2010-04-17T08:05:09.829551">0</PathFeedrate>

        </Samples>

        <Events>

          <Block dataItemId="cn2" name="block" sequence="746858893" timestamp="2010-04-17T08:05:08.597481">G0Z1</Block>

          <ControllerMode dataItemId="cn3" name="mode" sequence="746803685" timestamp="2010-04-17T08:01:45.149887">AUTOMATIC</ControllerMode>

          <Line dataItemId="cn4" name="line" sequence="746859056" timestamp="2010-04-17T08:05:09.861553">0</Line>

          <Program dataItemId="cn5" name="program" sequence="746803684" timestamp="2010-04-17T08:01:45.149887">FLANGE_CAM.NGC</Program>

          <Execution dataItemId="cn6" name="execution" sequence="746803674" timestamp="2010-04-17T08:01:45.149887">ACTIVE</Execution>

        </Events>                                         

      </ComponentStream>

    </DeviceStream>

  </Streams>

</MTConnectStreams>

The previous event shows the Execution in the ACTIVE state. The next step is to take the difference between the two time-stamps:

2010-04-17T08:05:09.905555 - 2010-04-17T08:01:45.149887 = 
       204.755668 Seconds or  00:03:24.755668

The technique can be used for any observed values in MTConnect since only the changes are recorded, the previous state will always be available using the current at the previous sequence number, even if the previous event is no longer in the buffer, but the previous sequence number is greater than the firstSequence number.

5.5        Streaming

When the interval parameter is provided, the MTConnect® Agent MUST find all available events, samples, and condition that match the current filter criteria specified by the path delayinginterval milliseconds between data or at its maximum possible rate. The interval indicates the delay between the end of one data transmission and the beginning of the next data transmission. A interval of zero indicates the Agent deliver data at its highest possible rate.

The interval MUST be given in milliseconds. If there are no available events or samples, the Agent MAY delay sending an update for AT MOST ten (10) seconds. The Agent MUST send updates at least once every ten (10) seconds to ensure the receiver that the Agent is functioning correctly. The content of the streams MUST be empty if no data is available for a given interval.

The format of the response MUST use a MIME encoded message with each section separated by a MIME boundary. Each section of the response MUST contain an entire MTConnectStreamsdocument.

For more information on MIME see rfc1521 and rfc822. This format is in use with most streaming web media protocols.

Request:                                                                        

http://localhost/sample?interval=1000&path=//DataItem[@type=”AVAILABILITY”]

Sample response:

1.   HTTP/1.1 200 OK

2.   Connection: close

3.   Date: Sat, 13 Mar 2010 08:33:37 UTC

4.   Status: 200 OK

5.   Content-Disposition: inline

6.   X-Runtime: 144ms

7.   Content-Type: multipart/x-mixed-replace;boundary=a8e12eced4fb871ac096a99bf9728425

8.   

Lines 1-8 are a standard header for a MIME multipart message. The boundary is a separator for each section of the stream. The content length is set to some arbitrarily large number or omitted. Line 10 indicates this is a multipart MIME message and the boundary between sections.

9.   --a8e12eced4fb871ac096a99bf9728425

10. Content-type: text/xml

11. Content-length: 887

12.  

13. <?xml version="1.0" encoding="UTF-8"?>

14. <MTConnectStreams xmlns:m="urn:mtconnect.org:MTConnectStreams:1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:mtconnect.org:MTConnectStreams:1.1" xsi:schemaLocation="urn:mtconnect.org:MTConnectStreams:1.1 http://www.mtconnect.org/schemas/MTConnectStreams_1.1.xsd">

15.   <Header creationTime="2010-03-13T08:33:37+00:00" sender="localhost" instanceId="1268469210" bufferSize="131072" version="1.1" nextSequence="43" firstSequence="1" lastSequence="42" />

16.   <Streams/>

17. </MTConnectStreams>

Lines 9-17 are the first section of the stream. Since there was no activity in this time period there are no component streams included. Each section presents the content type and the length of the section. The boundary is chosen to be a string of characters that will not appear in the message.

18. --a8e12eced4fb871ac096a99bf9728425

19. Content-type: text/xml

20. Content-length: 545

21.  

22. <?xml version="1.0" encoding="UTF-8"?>

23. <MTConnectStreams xmlns:m="urn:mtconnect.org:MTConnectStreams:1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:mtconnect.org:MTConnectStreams:1.1" xsi:schemaLocation="urn:mtconnect.org:MTConnectStreams:1.1 http://www.mtconnect.org/schemas/MTConnectStreams_1.1.xsd">

24.   <Header creationTime="2010-03-13T08:33:38+00:00" sender="localhost" instanceId="1268469210" bufferSize="131072" version="1.1" nextSequence="43" firstSequence="1" lastSequence="42" />

25.   <Streams>

26.     <DeviceStream name="VMC-4Axis" uuid="XXX111">

27.       <ComponentStream component="Device" name="VMC-4Axis" componentId="dev">

28.         <Events>

29.           <Availability dataItemId="avail" sequence="25" timestamp="2010-03-13T08:33:30.555235">UNAVAILABLE</Availability>

30.         </Events>

31.       </ComponentStream>

32.     </DeviceStream>

33.   </Streams>

34. </MTConnectStreams>

Lines 18-34: After a period of time, the power gets turned off and a new mime part is sent with the new status.

35. --a8e12eced4fb871ac096a99bf9728425

36. Content-type: text/xml

37. Content-length: 883

38.  

39. <?xml version="1.0" encoding="UTF-8"?>

40. <MTConnectStreams xmlns:m="urn:mtconnect.org:MTConnectStreams:1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:mtconnect.org:MTConnectStreams:1.1" xsi:schemaLocation="urn:mtconnect.org:MTConnectStreams:1.1 http://www.mtconnect.org/schemas/MTConnectStreams_1.1.xsd">

41.   <Header creationTime="2010-03-13T08:34:18+00:00" sender="localhost" instanceId="1268469210" bufferSize="131072" version="1.1" nextSequence="98" firstSequence="1" lastSequence="97" />

42.   <Streams>

43.     <DeviceStream name="VMC-4Axis" uuid="XXX111">

44.       <ComponentStream component="Device" name="VMC-4Axis" componentId="dev">

45.         <Events>

46.           <Availability dataItemId="avail" sequence="65" timestamp="2010-03-13T08:34:16.0312">AVAILABLE</Availability>

47.         </Events>

48.       </ComponentStream>

49.     </DeviceStream>

50.   </Streams>

51. </MTConnectStreams>

Lines 34-51: Approximately six seconds later the machine is turned back on and a new message is generated. Even though sample interval parameter (sample?interval=1000) is set to 1,000 milliseconds, the Agent waited for ten seconds to send a new XML document.

52. --a8e12eced4fb871ac096a99bf9728425

53. Content-type: text/xml

54. Content-length: 545

55.  

56. <?xml version="1.0" encoding="UTF-8"?>

57. <MTConnectStreams xmlns:m="urn:mtconnect.org:MTConnectStreams:1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:mtconnect.org:MTConnectStreams:1.1" xsi:schemaLocation="urn:mtconnect.org:MTConnectStreams:1.1 http://www.mtconnect.org/schemas/MTConnectStreams_1.1.xsd">

58.   <Header creationTime="2010-03-13T08:34:27+00:00" sender="localhost" instanceId="1268469210" bufferSize="131072" version="1.1" nextSequence="98" firstSequence="1" lastSequence="97" />

59.   <Streams />

60. </MTConnectStreams>

Lines 52-60 demonstrate a heartbeat sent out 10 seconds after the previous message. Since there is no activity there is no content in the device streams element.

The Agent MUST continue to stream results until the client closes the connection. The Agent MUST NOT stop the streaming for any other reason other than the Agent process shutting down.

5.6        Asset Requests

The MTConnect agent is capable of storing a limited number of assets. An Asset is something that is associated with the manufacturing process that is not a component of a device, can be removed without detriment to the function of the device, and can be associated with other devices during their lifecycle.

The assets are referenced by their asset id. The id is a permanent identifier that will be associated with this asset for its entire life.

When an asset is added or modified, the agent will generate an AssetAdded event or an AssetModified event for the device. For devices that manage assets, these data items MUST be added to the data items list at the device level.

The agent MUST store one or more assets. It MAY decide the capacity based on the available storage and scalability of the implementation. Similar to Events, Samples, and Conditions, the data will be managed on a first in first out basis.

The asset’s timestamp will be used to determine the oldest asset for removal. As assets are modified, their timestamp is updated to the current time. As with all timestamps in MTConnect, the time will be given using the UTC (or GMT) timezone.

5.7        HTTP Response Codes and Error

MTConnect® uses the HTTP response codes to indicate errors where no XML document is returned because the request was malformed and could not be handled by the Agent. These errors are serious and indicate the client application is sending malformed requests or the Agent has an unrecoverable error. The error code MAY also be used for HTTP authentication with the 401 request for authorization. The HTTP protocol has a large number of codes defined[1]; only the following mapping MUST be supported by the MTConnect® Agent:

HTTP 
Status

Name

Description

200

OK

The request was handled successfully.

400

Bad Request

The request could not be interpreted.

500

Internal Error

There was an internal error in processing the request. This will require technical support to resolve.

501

Not Implemented

The request cannot be handled on the server because the specified functionality is not implemented.


5.7.1 MTConnectError

The MTConnectError document MUST be returned if the Agent cannot handle the request. The Error contains an errorCode and the CDATA of the element is the complete error text. The classification for errors is expected to expand as the standard matures.

For backward compatibility, MTConnectError can contain a single Error element. If there is more than one error to report, it is up to the implementation of the Agent to determine the most important error to include.

5.7.2 Errors

The MTConnectError element MUST contain all relevant errors for the given request. The Errors element MUST contain at least one Error element. There are no attributes for this element.

5.7.3 Error

The Error contains an errorCode and the CDATA of the element is the complete error text. The classification for errors is expected to expand as the standard matures.


Attributes

Description

Occurrence

errorCode

An error code

1



The CDATA of the Error element is the textual description of the error and any additional information the Agent wants to send. The Error element MUST contain one of the following error codes:

Error Code

Description

UNAUTHORIZED

The request did not have sufficient permissions to perform the request.

NO_DEVICE

The device specified in the URI could not be found.

OUT_OF_RANGE

The sequence number was beyond the end of the buffer.

TOO_MANY

The count given is too large.

INVALID_URI

The URI provided was incorrect.

INVALID_REQUEST

The request was not one of the three specified requests.

INTERNAL_ERROR

Contact the software provider, the Agent did not behave correctly.

INVALID_XPATH

The XPath could not be parsed. Invalid syntax or XPath did not match any valid elements in the document.

UNSUPPORTED

A valid request was provided, but the Agent does not support the feature or request type.

ASSET_NOT_FOUND

An asset ID cannot be located.



Here is an example of an HTTP error:

1.   HTTP/1.1 200 Success

2.   Content-Type: text/xml; charset=UTF-8

3.   Server: Agent

4.   Date: Sun, 23 Dec 2007 21:10:19 GMT

5.    

6.   <?xml version="1.0" encoding="UTF-8"?>

7.   <MTConnectError xmlns="urn:mtconnect.org:MTConnectError:1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="urn:mtconnect.org:MTConnectError:1.1 http://www.mtconnect.org/schemas/MTConnectError_1.1.xsd">

8.    <Header creationTime="2010-03-12T12:33:01" sender="localhost" version="1.1" bufferSize="131000" instanceId="1" />

9.    <Errors>

10.   <Error errorCode="OUT_OF_RANGE" >Argument was out of range</Error>

11.   <Error errorCode="INVALID_XPATH" >Bad path</Error>

12.  </Errors>

13. </MTConnectError>

5.8        Protocol Details

When an MTConnect® Agent collects information from the device, it assigns each piece of information a unique sequence number. The sequence number MUST be assigned in monotonically increasing numbers in the order they arrive at the Agent. Each source SHOULD provide a time-stamp indicating when the information was collected from the component. If no time-stamp is provided, the Agent MUST provide a time-stamp of its own. The time-stamps reported by the Agent MUST be used as the means for the ordering of the messages as opposed to using the sequence number for this purpose.

Note: It is assumed the time-stamp is the best available estimate of when the data was recorded.

If two data items are sampled at the same exact time, they MUST be given the same time stamp. It is assumed that all events or samples with the same timestamp occurred at the same moment. A sample is considered to be valid until the time of the next sample for the same data item. If no new samples are present for a data item, the last value is maintained for the entire period between the samples. Important: MTConnect® only records data when it changes. If the value remains the same, MTConnect MUST NOT record a duplicate value with a new sequence number and time stamp. There MUST NEVER be two identical adjacent values for the same data item in the same component.

For example, if the Xact is 0 at 12:00.0000 and Yact is 1 at 12:00.0000, these two samples were collected at the same moment. If Yact is 2 at 12:01.0000 and there is no value at this point for Xact, it is assumed that Xact is still 0 and has not moved.

The sequence number MUST be unique for this instance of the MTConnect® Agent, regardless of the device or component the data came from. The MTConnect® Agent provides the sequence numbers in series for all devices using the same counter. This allows for multi-device responses without sequence number collisions and unnecessary protocol complexity.

As an implementation warning, it is the applications responsibility to make sure it does not miss information from the Agent. The Agent has no awareness of the application or the application’s requirements for data, and it therefore does not guarantee the application receive all pieces of data. The Agent protocol makes it easy for the application developers to determine if they have received all pieces of data by scrolling through the buffer. If they ever receive an OUT_OF_RANGE error due to providing a from argument that references a sequence number prior to the beginning of the retained data, they know they have missed some information.

If the application only uses current requests, it may miss information since it will only be receiving a snapshot at various points in time. For some display application that do not need to store or reason on the data, this may be adequate, but if more in-depth analysis is to be performed, it is advised that the application make requests based on their data requirements using filtering and streams to get all vital information. For example, the application can request all condition types and controller events, and then sample other pieces of data for which they have less strict requirements. Breaking things out like this will allow for continuous data flow and minimal bandwidth utilization.

The application may request any sequence of data within the buffer at any time using either the sample from or the current at semantics. With these two calls it is easy for the application to go back in time and find data prior to an occurrence. It is of course limited to the size of the buffer and rate of incoming data.

5.8.1      Buffer Semantics

The MTConnect buffer can be thought of as a tube that can hold a finite set of balls. As balls are inserted in one end they fill the tube until there is no more room for additional balls at which point any new balls inserted will push the oldest ball out the back of the tube. The tube will continue to shift in this mannor with monotonically increasing sequence numbers being assigned as each ball gets inserted. The sequence numbers will never be reused for one instance of the Agent process. Since the sequence number is a 64 bit integer, the numbers will never (at least within the next 100,000 years) wrap around or be exhausted.

The following example is a contrived agent with only 8 slots and two data item types, a Line (Line) event and a Position (Pos) sample. The Position sample at sequence number 19 was just inserted and the event at sequence number 11 was just removed.


Figure 12: Example Buffer 1

If we perform a current request, we will receive Line 227 and Pos 22. If the at parameter is given to the current request and is set to 12, we will receive Line 201 and Position 0, and as follows at 13 will retrieve Line 201 and Position 10. Note: The last value for all Events, Samples, and each Condition will be preserved until they are replaced. Therefore, Line 201 is returned since it has not been replaced until sequence number 14 where Line is 210.

If a current request is made for a sequence number prior to 12, the agent MUST return a OUT_OF_RANGE error. For example, a request for current at 11 will result in OUT_OF_RANGEerror. The same error MUST be given if a sequence number is requested that is greater than the end of the buffer. For example, a request for current at 20 will result in an OUT_OF_RANGE error.


Figure 13: Buffer Semantics 2

The above illustration show what happens when another Line event is added at sequence number 20. The Pos 0 is sample is pushed out the back of the pipe and the first available sequence number is now 13. A request for the current at 13 will still retrieve a Line of 201, since the first value for line has not been replaced. The value for Line 201 MUST be retained until 13 rolls off the end and the firstSequence number is 14.

If no previous value for line is available, then the value for the line MUST be UNAVAILABLE. This is true for recovery as well when the data is restored from a persistent store, any data items that can not be restored to a previous value MUST be marked as UNAVAILABLE.

5.8.2      Buffer Windows

The information in MTConnect® can be thought of as a four column table of data where the first column is a sequence number increasing by increments of one, the second column is the time, the third column is the data item it is associated with, and the fourth column is the value. The storage, internal representation, and implementation is not part of this standard. The implementer can choose to store as much or as little information as they want, as long as they can support the requirements of the standard. They can also decide if it is necessary to locally store the data.

The following examples will use only a single device. Multiple devices are treated the same as single devices. We will document the multiple device scenarios in more depth in future versions of this standard.

The following table is an example of a small window of data collected from a device:


Figure 14: Sample Data in an Agent

Figure 14 is a table of 25 data values and a duration of around 12 seconds. The data captures the Availability of the device and the position of its axes: the linear axes X, Y, and Z, and the rotary axis C. The only data items collected in this example are the Position (for the sake of this data, we have the actual position) and the rotary axis C Spindle Speed. We are also collecting the device’s Availability state that can be either AVAILABLE or UNAVAILABLE. The device is UNAVAILABLE when the sample starts.

For the remainder of the examples we will be excluding the time column to save space.

5.9        Request without Filtering

In the example below, the application made a request for a sample starting at sequence #101 and retrieves the next eleven items. The response will include all the Samples, Events, and Condition in the mill device from 101 to 112. The nextSequence number in the header will tell the application it should begin the next request at 113. (The response is abbreviated and for illustration purpose only.)


Figure 15: Example #1 for Sample from Sequence #101

In the following illustration, the next request starts at 113 and gets the next ten samples. The response will include the X, Y, Z, and C samples and since there are no Availablity events, this component will not be included:


Figure 16: Example #1 for Sample from Sequence #113

In the above illustration, only the four axis components have samples. One will only get samples or events if they occur in the window being requested. In the next illustration, the application will request the next ten items starting at sequence number 123.


Figure 17: Example #1 for Sample from Sequence #124

In the above illustration, there are only three items available. The first two are axis samples and the third is an Availability event. The next sequence will indicate that the application must request Samples, Events, and Condition starting at 127 for the next group. If the application were to do this, it would receive an empty response with the nextSequence of 127 indicating that no data was available.

The next sequence number MUST always be the largest sequence number of available items in the selection window plus one. If the request indicated a from of 10 and a count of 10, the MTConnect® MUST consider at most 10 items if available. If the value for from is larger than the last item’s sequence number + 1, an OUT_OF_RANGE error MUST be returned from the Agent.

The same rule will be applied to the current request as well. In the instance of the current request, the next sequence MUST be set to the one greater than the last item’s sequence number in the table of data values. Since current always considers all Events, Condition, and Samples , it MUST always be one greater than the maximum sequence number assigned.

5.10    Request with Filtering using Path Parameter

The next set of examples will show the behavior when a path parameter is provided.


Figure 18: Example #2 for Sample from Sequence #101 with Path

Figure 16 shows that when events are filtered for only the Availability DataItem, the Availability is UNAVAILABLE event will be delivered and nothing else. The Availability AVAILABLE event is sequence number 101, but since the other Samples, Events, and Condition are considered, the next sequence number is still 113. The MTConnect® Agent MUST set the next sequence number to one greater (+1) than the last event or sample in the window of items being considered. The Agent MUST consider all the Events, Condition, and Samples evaluated in the process of formulating the response to the application.

In the next illustration the request is sent as before but now only including Availability data items:


Figure 19: Example #2 for Sample from Sequence #112 with Path

An empty XML element representing the device MUST be returned to indicate that the request was valid and no data was found since there were no Availability events in the given range. The nextSequence in the case MUST be set to 113 even though no results were returned. If this was not done, the application would continue to request sequence starting at 113 indefinitely.


To continue this example, the last request will start at 123 as before and will now request only Availability DataItem:


Figure 20: Example #2 for Sample from Sequence #123 with Path

As can be seen, the one Availability event is returned and the next sequence is now 127. This will indicate that the application must request from 127 on for the next set of events. If no events are available, the nextSequence will again be set to 127 and an empty DeviceStream will be returned.

5.11    Fault Tolerance and Recovery

MTConnect® does not provide a guaranteed delivery mechanism. The protocol places the responsibility for recovery on the application.

5.11.1 Application Failure

The application failure scenario is easy to manage if the application persists the next sequence number after it processes each response. The MTConnect® protocol provides a simple recovery strategy that only involves reissuing the previous request with the recovered next sequence number.

There is the risk of missing some Events, Samples, and Condition if the time between requests exceeds the capacity of the Agent’s buffer. In this case, there is no record of the missing information and it is lost. If the application automatically restarts after failure, the intervening data can be quickly recovered


Figure 21: Application Failure and Recovery

If this cannot be done, the current state of the device can be retrieved and the application can continue from that point onward.

5.11.2 Agent Failure

Agent failure is the more complex scenario and requires the use of the instanceId. The instanceId was created to facilitate recovery when the Agent fails and the application is unaware. Since HTTP is a connectionless protocol, there is no way for the application to easily detect that the Agent has restarted, the buffer has been lost, and the sequence number has been reset to 1. It should also be noted that all values will be reinitialized to UNAVAILABLE upon agent restart except for data items that are constrained to single values. See Part 1, Section 5.12 on Unavailability of Data for a full explanation.

 

Figure 22: Agent Failure and Recovery

In the above example, the instanceId is increased from 1 to 2 indicating that there was a discontinuity in the sequence numbers and all values for the data items are reset to UNAVAILABLE. When the application detects the change in instanceId, it MUST reset its next sequence number and retry its request from sequence number 1. The next request will retrieve all data starting from the first available event or sample.

5.11.3   Data Persistence and Recovery

The implementer of the Agent can decide on the strategy regarding the storage of Events, Condition, and Samples. In the simplest form, the Agent can persist no data and hold all the results in volatile memory. If the Agent has a method of persisting the data fast enough and has sufficient storage, it MAY save as much or as little data as is practical in a recoverable storage system.

If the Agent can recover data and sequence numbers from a storage system, it MUST NOT change the instanceId when it restarts. This will indicate to the application that it need not reset the next sequence number when it requests the next set of data from the Agent.

If the Agent persists no data, then it MUST change the instanceId to a different value when it restarts. This will ensure that every application receiving information from the Agent will know to reset the next sequence number.

The instanceId can be any unique number that will be guaranteed to change every time the Agent restarts. If the Agent will take longer than one second to start, the UNIX time (seconds since January 1, 1970) MAY be used for identification an instance of the MTConnect® Agent in the instanceId.

5.12  Unavailability of Data

Every time the Agent is initialized all values MUST be set to UNAVAILABLE unless they are constant valued data items as described in Section 5.12.2 Constant Valued Data Items below. Even during restarts this MUST occur so that the application can detect a discontinuity of data and easily determine that gap between the last reported valid values.

In the event no data is available, the value for the data item in the stream MUST be UNAVAILABLE. This value indicates that the value is currently indeterminate and no assumptions are possible. MTConnect® supports multiple data sources per device, and for that reason, every data item MUST be considered independent and MUST maintain its own connection status.

In the following example, the data source for a temperature sensor becomes temporarily disconnected from the Agent. At this point the value changes from the current temperature toUNAVAILABLE since the temperature can no longer be determined.

In figure 17, the temperatures range around 100 until it becomes disconnected and then in the future it reconnects and the temperature is 30. Between these two points assumptions SHOULD NOTbe made as to the temperature since no information was available.


Figure 23: Unavailable Data from Machine

If data for multiple data items are delivered from one source and that source becomes unavailable, all data items associated with that source MUST have the value UNAVAILABLE. This MUST be a synchronous operation where all related data items will get that value with the same time stamp. The value will remain UNAVAILABLE until the data source has reconnected.

5.12.1   Examples

1.   <Linear name=”X” id=”x”>

2.     <DataItems>

3.       <DataItem type=”POSITION” category=”SAMPLE” id=”Xpos” … />

4.       <DataItem type=”TEMPERATURE” category=”SAMPLE” id=”Ctemp” … />

5.     </DataItems>

6.   </Linear>

When the Agent is started and has no initial information about the device, all data item value MUST have the value UNAVAILABLE. This will produce the following results to a current request:

<ComponentStream component="Linear" componentId="x" name="X">

  <Samples>

   <Position timestamp="2010-03-01T11:59:09.001" dataItemId="Xpos" sequence="99" >UNAVAILABLE</Position>

   <Temperature timestamp="2010-03-01T11:59:09.001" dataItemId="Xpos" sequence="100" >UNAVAILABLE</Temperature>

  </Samples>

</ComponentStream>

 

Once the adapters are connected, the values will no longer be UNAVAILABLE. The results from the current once again:

<ComponentStream component="Linear" componentId="x" name="X">

  <Samples>

   <Position timestamp="2010-03-01T12:09:31.021" dataItemId="Xpos" sequence="122" >13.0003</Position>

   <Temperature timestamp="2010-03-01T12:07:22.031" dataItemId="Xpos" sequence="113" >102</Temperature>

  </Samples>

</ComponentStream>

 

If the temperature sensor should lose power and become disconnected, as shown in figure 17, the following response will be given by current.

<ComponentStream component="Linear" componentId="x" name="X">

  <Samples>

   <Position timestamp="2010-03-01T12:12:19.311" dataItemId="Xpos" sequence="212" >1.0003</Position>

   <Temperature timestamp="2010-03-01T12:15:41.121" dataItemId="Xpos" sequence="199" >UNAVAILABLE</Temperature>

  </Samples>

</ComponentStream>

 

The X position has a valid value and only the Temperature is unknown. When a sample is requested, the value UNAVAILABLE will be treated the same as any other value for the data item.

<ComponentStream component="Linear" componentId="x" name="X">

  <Samples>

   <Position timestamp="2010-03-01T11:59:09" dataItemId="Xpos" sequence="212" >1.0003</Position>

   <Position timestamp="2010-03-01T11:59:09" dataItemId="Xpos" sequence="212" >2.2103</Position>

   <Position timestamp="2010-03-01T11:59:09" dataItemId="Xpos" sequence="212" >4.3303</Position>

   <Temperature timestamp="2010-03-01T11:59:09" dataItemId="Xpos" sequence="199" >101</Temperature>

   <Temperature timestamp="2010-03-01T11:59:09" dataItemId="Xpos" sequence="199" >103</Temperature>

   <Temperature timestamp="2010-03-01T11:59:09" dataItemId="Xpos" sequence="199" >UNAVAILABLE</Temperature>

  </Samples>

</ComponentStream>

 

5.12.2   Constant valued data items

If the data item is constrained to one value, the initial value for this data item MUST be that value. For example:

1.   <Rotary name=”C” id=”C” nativeName=”S”>

2.     <DataItems>

3.       <DataItem type=”ROTARY_MODE” category=”EVENT” id=”Cmode”>

4.        <Constraints><Value>SPINDLE</Value></Constraints>

5.       </DataItem>

6.       <DataItem type=”SPINDLE_SPEED” category=”SAMPLE” id=”Cspeed”/>

7.     </DataItems>

8.   </Rotary>


In this example, the RotaryMode MUST be initialized to SPINDLE. If an application was to request data from this device before the adapter was connect, the result MUST be the following:

<ComponentStream component="Rotary" componentId="c" name="C">

  <Events>

   <RotaryMode timestamp="2010-03-01T11:58:09" dataItemId="Cmode" sequence="1" >SPINDLE</Position>

  <Events>

  <Samples>

   <SpindleSpeed timestamp="2010-03-01T11:59:09" dataItemId="Cspeed" sequence="113" >UNAVAILABLE</Temperature>

  </Samples>

</ComponentStream>


The SpindleSpeed shows UNAVAILABLE as described above, but the RotaryMode is assigned the constant value SPINDLE since it can only have one value. The value for RotaryModeMAY NOT be delivered by the Adapter and if it is, it MUST be SPINDLE.

For more information on Constraints, see MTConnect Part 2, Section 4.1.2 – Data Item Element.

Appendices

A.  Bibliography

1.     Engineering Industries Association. EIA Standard - EIA-274-D, Interchangeable Variable, Block Data Format for Positioning, Contouring, and Contouring/Positioning Numerically Controlled Machines. Washington, D.C. 1979.

2.     ISO TC 184/SC4/WG3 N1089. ISO/DIS 10303-238: Industrial automation systems and integration  Product data representation and exchange  Part 238: Application Protocols: Application interpreted model for computerized numerical controllers. Geneva, Switzerland, 2004.

3.     International Organization for Standardization. ISO 14649: Industrial automation systems and integration – Physical device control – Data model for computerized numerical controllers – Part 10: General process data. Geneva, Switzerland, 2004.

4.     International Organization for Standardization. ISO 14649: Industrial automation systems and integration – Physical device control – Data model for computerized numerical controllers – Part 11: Process data for milling. Geneva, Switzerland, 2000.

5.     International Organization for Standardization. ISO 6983/1 – Numerical Control of machines – Program format and definition of address words – Part 1: Data format for positioning, line and contouring control systems. Geneva, Switzerland, 1982.

6.     Electronic Industries Association. ANSI/EIA-494-B-1992, 32 Bit Binary CL (BCL) and 7 Bit ASCII CL (ACL) Exchange Input Format for Numerically Controlled Machines. Washington, D.C. 1992.

7.     National Aerospace Standard. Uniform Cutting Tests - NAS Series: Metal Cutting Equipment Specifications. Washington, D.C. 1969.

8.     International Organization for Standardization. ISO 10303-11: 1994, Industrial automation systems and integration  Product data representation and exchange  Part 11: Description methods: The EXPRESS language reference manual. Geneva, Switzerland, 1994.

9.     International Organization for Standardization. ISO 10303-21: 1996, Industrial automation systems and integration -- Product data representation and exchange -- Part 21: Implementation methods: Clear text encoding of the exchange structure. Geneva, Switzerland, 1996.

10.  H.L. Horton, F.D. Jones, and E. Oberg. Machinery's handbook. Industrial Press, Inc. New York, 1984.

11.  International Organization for Standardization. ISO 841-2001: Industrial automation systems and integration - Numerical control of machines - Coordinate systems and motion nomenclature. Geneva, Switzerland, 2001.

12.  ASME B5.59-2 Version 9c: Data Specification for Properties of Machine Tools for Milling and Turning. 2005.

13.  ASME/ANSI B5.54: Methods for Performance Evaluation of Computer Numerically Controlled Lathes and Turning Centers. 2005.

14.  OPC Foundation. OPC Unified Architecture Specification, Part 1: Concepts Version 1.00. July 28, 2006.

15.  View the following site for RFC references: http://www.faqs.org/rfcs/ .

B.   Discovery

The deployment of MTConnect® SHOULD use a separate service to aid applications in locating and communicating with devices. If discovery is employed, the MTConnect® Agent MUSTregister all the devices in an LDAP server so each device’s Agent can be located on the network with an HTTP URI. The device entry in LDAP MUST include a labeledURIObject andMUST specify the labeledURI field. Other information MAY be added to the LDAP device record depending on the needs of the application and the organization.

Applications MAY require the ability to locate devices and it is best handled by the discovery service. The implementation SHOULD NOT assume that one Agent will be providing data for all the devices. If one wants to find all the devices available for data collection using the MTConnect® protocol, they SHOULD use an LDAP server to organize their equipment and resolve the machine names into valid URIs.

If discovery is not provided or used, the application MUST know the URI for the device’s Agent and address it directly.

B.1.   Physical Architecture

The diagram below is an example of a shop floor with three devices, one management application, and one Name Service. There are two MTConnect® Agents in this deployment. One of the MTConnect® Agents is serving two pieces of equipment (lathe-1 and lathe-2) and the other Agent is embedded in the controller of the mill. The management application is monitoring all three pieces of equipment.


Figure 24: Shop Illustration

One can look up the three devices using the Name Service. The application would search for all devices in the Equipment organization unit (ou=Equipment,dc=example,dc=com). The application would get back three device names: lathe-1lathe-2, and mill-1. These would be have the following URIs: http://10.1.10.32/lathe-1,http://10.1.10.32/lathe-2, and http://10.1.10.33/mill-1.

The application can thereafter use the URIs to query the devices for the components and the data they can supply.


[1] For a full list of HTTP response codes see the following document: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html