| title | description | published | date | tags | editor | dateCreated |
|---|---|---|---|---|---|---|
HTTP Primer |
true |
2021-09-25 02:14:11 UTC |
markdown |
2021-09-24 00:31:37 UTC |
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.
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.)
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).
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 above illustrates the initialization of the Agent and communication with the device “mill”. Implementors Note: This is the recommended architecture and implementations SHOULD refer 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.
Figure 2 above 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.
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. As seen in Figure 3 below, 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 Figure 3, 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 the (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 Agent MUST 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.
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 Tool SHOULD be identified by the tool ID and serial number as a composed synthetic identifier.
As in this Figure 4, 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:
- url: http://example.com/asset/hh1 Returns the MTConnectAssets document for asset hh1
-
Request multiple assets by ID:
- url: http://example.com/asset/hh1;cc;123;g5 Returns the MTConnectAssets document for asset hh1, cc, 123, and g5.
-
Request for all the assets in the Agent:
- url: http://example.com/assets
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.
- url: http://example.com/assets
-
Request for all assets of a given type in the Agent:
- url: http://example.com/assets?type=”CuttingTool”
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.
- url: http://example.com/assets?type=”CuttingTool”
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 2³² can 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.