HiveMQ MTConnect Protocol is a Java implementation of the MTConnect protocol.
- Support MTConnect Schemas
| MTConnect Schema | Version |
|---|---|
| Assets | 1.2 - 2.4 |
| Devices | 1.0 - 2.4 |
| Error | 1.1 - 2.4 |
| Streams | 1.1 - 2.4 |
- Support Conversion from MTConnect XML to Java Entities
- Support MTConnect Schema Version Detection
<dependency>
<groupId>com.hivemq</groupId>
<artifactId>hivemq-mtconnect-protocol</artifactId>
<version>1.0.0</version>
</dependency>
<dependency>
<groupId>jakarta.xml.bind</groupId>
<artifactId>jakarta.xml.bind-api</artifactId>
<version>4.0.2</version>
</dependency>
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-impl</artifactId>
<version>4.0.5</version>
</dependency>implementation 'com.hivemq:hivemq-mtconnect-protocol:1.0.0'
implementation 'jakarta.xml.bind:jakarta.xml.bind-api:4.0.2'
implementation 'com.sun.xml.bind:jaxb-impl:4.0.5'implementation("com.hivemq:hivemq-mtconnect-protocol:1.0.0")
implementation("jakarta.xml.bind:jakarta.xml.bind-api:4.0.2")
implementation("com.sun.xml.bind:jaxb-impl:4.0.5")// Extract the schema location from an XML string.
String schemaLocation = MtConnectSchema.extractSchemaLocation(xmlString);
// Get the MTConnect schema from a schema location.
MtConnectSchema schema = MtConnectSchema.of(schemaLocation);
// Convert an XML string to an MTConnect entity.
try (StringReader stringReader = new StringReader(xmlString)) {
JAXBElement<?> element = (JAXBElement<?>) unmarshaller.unmarshal(stringReader);
com.hivemq.mtconnect.protocol.schemas.streams.streams_2_0.MTConnectStreamsType
mtConnectStreamsType =
(com.hivemq.mtconnect.protocol.schemas.streams.streams_2_0.MTConnectStreamsType) element.getValue();
}The Schema validation is XSD based. That implies a considerable performance overhead if the validation is performed per message. In general, there are 2 options:
- No Validation - Turn off the schema validation.
- Complete Validation - Implement the validation in Java to improve the performance.
| No Validation | Complete Validation | |
|---|---|---|
| Performance | Excellent | Slow |
| Dev Cost | Low | High |
| Malformed Schema | Allow | Disallow |
| Custom Schema | Support | Not Support |
| Type Cast | Loose | Strict |
- Download jaxb-ri and unzip it to
hivemq-mtconnect-protocolfolder. - Download Xerces2 Java Binary (XML Schema 1.1) and unzip it to
hivemq-mtconnect-protocolfolder. git clone https://github.com/mtconnect/schema.gitto tohivemq-mtconnect-protocolfolder. Here is a sample directory structure.
hivemq-mtconnect-protocol
├── jaxb-ri
├── schema
└── xerces-2_12_2-xml-schema-1.1
- Run all test cases in
MtConnectSchemaPatchTestto generate the schema patch files. By default, those test cases are skipped ifschemafolder is not found. - Navigate to
schemaand run./patch-script.shto generate all the XML entities. - After all the XML entities are generated, run all test cases
MtConnectSchemaJsonAnnotationTestto convert the XML annotations to Jackson annotations. This is a one-time process and the test case is able to generate the Jackson annotations in an incremental way. By default, those test cases are skipped ifjaxb-riorxercesis not found.
parsing a schema...
[ERROR] Property "Type" is already defined. Use <jaxb:property> to resolve this conflict.
line 5174 of file:/.../schema/MTConnectDevices_1.5.xsd
[ERROR] The following location is relevant to the above error
line 5064 of file:/.../schema/MTConnectDevices_1.5.xsdThis issue is caused by the absence of property name in <xs:attribute ref='xlink:type' use='optional' fixed='locator'>...</xs:attribute>. So the default property name becomes type which conflicts with the inherited property type as the name. Test cases in MtConnectSchemaPatchTest are able to fix this issue. One of the test cases generates some patch files like the one below to tell xjc to use the property typeOfDeviceRelationship instead of type as name so that the conflict can be resolved.
<?xml version='1.0' encoding='UTF-8'?>
<bindings xmlns="http://java.sun.com/xml/ns/jaxb"
xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
xmlns:xs="http://www.w3.org/2001/XMLSchema" version="2.1">
<bindings schemaLocation="MTConnectDevices_1.5.xsd" version="1.0">
<bindings node="//xs:complexType[@name='DeviceRelationshipType']">
<bindings node=".//xs:attribute[@ref='xlink:type']">
<property name="typeOfDeviceRelationship"/>
</bindings>
</bindings>
</bindings>
</bindings>EventType and EntryType in streams 1.5+ are marked as abstract='true' and mixed='true'. That tells xjc to generate the String content property in the base types. However, in derived types the content can be a list of Entry, Cell, etc. nodes. Obviously xjc cannot generate a second content in the derived classes because javac doesn't allow that. So xjc silently ignores those Entry, Cell, etc. nodes. That causes the MTConnect XML data to be invalid. The workaround is to mark mixed='false' in both the base types and the derived types. Some test cases in MtConnectSchemaPatchTest are able to fix this issue by automating the patching process via XPath.
There is a Smart Manufacturing Systems (SMS) Test Bed offering Volatile Data Stream (VDS).