HTTP Primer

From MTConnect® User's Portal
Revision as of 14:51, 29 July 2013 by Tjones25 (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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 MUST represent 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.

Components The building blocks of the device.

DataItems The description of the data available from the device.

Streams A set of Samples, Events, or Conditon for components and devices.

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.

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

Condition A piece of information the device provides as an indicator of its health and ability to function. A condition can be one of Normal, Warning, Fault, 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.

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.)

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).