Serdar Gökay created CAMEL-26376:
------------------------------------
Summary: camel-mtconnect - New component to read machine tools
through their MTConnect agent
Key: CAMEL-26376
URL: https://issues.apache.org/jira/browse/CAMEL-26376
Project: Camel
Issue Type: New Feature
Reporter: Serdar Gökay
MTConnect (ANSI/MTC1.4-2018) is the open standard machine tool vendors ship for
reading their machines: a read-only HTTP agent that answers {{probe}} (device
model), {{current}} (latest values), {{sample}} (a range or an open stream of
observations) and {{assets}} (cutting tools, NC programs) with XML documents.
Mazak, Okuma, DMG MORI, Haas, Makino and the Fanuc and Siemens adapters ship or
support such an agent; it is the machine tool counterpart of OPC UA, and the
two are what a CNC speaks to the outside. Camel has {{camel-milo}} for OPC UA
and nothing for MTConnect, and the Kamelet catalog has nothing either.
*Where it sits.* A machine tool integration is: the machine's agent on one
side, and on the other side whatever the plant runs, an MES or ERP (job and
tool status, SAP PM/PP), a broker or unified namespace (MQTT, Kafka), a
historian or database, condition monitoring and OEE. Camel already has every
component for the second side. This component is the missing first side: it
turns the agent's protocol into ordinary Camel messages, one per observation,
with the device, component, data item, units, sequence and quality on the
message, so the rest of the route is plain Camel.
*Why a component and not a route.* We first built it as a route: {{http}} +
{{timer}} + a Groovy script of about 140 lines holding the state machine
(probe, current, {{sample?from=}}, {{OUT_OF_RANGE}} resynchronisation,
{{instanceId}} re-probe, per-item {{Bad}} quality on timeouts). It worked
against the same agents, and showed why it does not belong in a route:
* The agent's streaming {{sample}} answer is a multipart stream that never
ends; {{camel-http}} reads a response as a whole, so a route can only poll.
Polling adds a round trip per interval per machine and the latency of the
interval; streaming delivers each observation as it happens on one open
connection.
* The protocol's correctness is in the details a route hides in a script: the
sequence cursor across outages, the buffer overrun ({{OUT_OF_RANGE}}, HTTP 400
on 2.x agents but 200 on 1.x agents), the agent restart, the probe metadata
that every observation needs, the asset changes a lost event can hide,
{{UNAVAILABLE}} versus unreachable. Each machine, each integration repeats and
re-debugs the same 140 lines; a component carries them once, with 104 tests.
* A script in a route is invisible to Camel's tooling: the catalog cannot
validate the options, the docs cannot describe the headers, Camel JBang and the
MCP tools cannot explain it to a developer or an agent. As a component every
option and header is declared and documented.
This issue proposes a new component {{camel-mtconnect}} (scheme {{mtconnect}}),
consumer and producer:
* Consumer: runs the protocol against one agent (probe, current, then the
streaming sample request, or polling with {{streaming=false}}), one message per
observation with the value as body and the MTConnect metadata (device,
component, data item, category, type, units, sequence, timestamp, quality) as
{{CamelMTConnect*}} headers. It keeps the sequence cursor across outages,
resynchronises from {{current}} on {{OUT_OF_RANGE}}, re-reads the device model
when the agent's {{instanceId}} changes, reports an unreachable agent once per
data item with quality {{Bad}}, and with {{assets=true}} also delivers the
agent's assets and their changes.
* Producer: {{operation=probe|current|sample|assets}} with the request
parameters as options or headers; the device model and asset documents are
returned as the agent's XML, observations as a list of maps with the same
fields as the consumer's headers.
* TLS through {{sslContextParameters}} (and the global SSL context parameters),
gzip for document answers.
* Implementation on the JDK HTTP client, no third-party dependency; documents
parsed with StAX by local name (schemas 1.3 to 2.5 and vendor namespaces), DTDs
and external entities disabled.
The code is complete and tested: 104 unit tests against an in-process stub
agent (two agent dialects, outages, overrun, restart, TLS, compression, assets,
polling), and live runs against a cppagent 2.8 (the reference implementation),
Mazak 1.4 and 1.6 vendor agents and demo.mtconnect.org over https. A pull
request follows this issue. We (Etzel) run the component in production
integrations and will maintain it.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
