This is a discussion of the concepts behind MTConnect's use of the HTTP protocol and the REST philosophy it has adopted. It will also discuss some best practices for implementing a client application to take advantage of Fault Tolerant capabilities built into the protocol as well as the ability to never miss a single event. We will also discuss how to use filtering to get just what you want and how best to create an application that uses multiple data streams from the same source depending on the data requirements.
MTConnect and REST
The MTConnect standard does not define its own protocol, but leverages the industry standard HTTP protocol and adds some RESTful interfaces on top of it. REST stands for REpresentational State Transfer. The term was first coined by Fielding in Chapter 5 of his thesis. The ideas of REST revolve around state management and who is responsible for managing connections and the data for that connection like the last message consumed and what information they are interested in. At the time of the paper, there was a lot of debate about the best way to architect web applications and manage client session state, which was a major limitation on server scalability and posed problems with replication and recovery.
The idea is that each request contains all the information necessary for the server to respond. The server does not need to keep any information about the clients who are making requests and just responds with the state given the parameters in the clients request. This architecture has now become the defacto standard for most large web application interfaces like AWS, [Twitter] and most other web services you can think of. There are many architectural benefits to providing a REST API; for more information, read the wikipedia article on Representational state transfer.
In the case of MTConnect, the Agent has no knowledge of the clients making the request – all context must be passed in the URL and the response will contain all information the client needs to manage the results. In this way we use the REST methodology to reduce the complexity of the Agent but still provide a fully Fault Tolerant and scalable protocol.
Typical Client / Agent Conversation
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 probe will 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 nextSequence number 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 from parameter for the next request.
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 unre-lated standard conversations occurring simultaneously with the MTConnect Agent, each poten-tially referencing different data or data types and using different portions of the Agent's data ta-ble.
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 MUST always 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.
- The second does not specify the device and therefore retrieves information for all devices:
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.