[
https://issues.apache.org/jira/browse/CAMEL-26376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Serdar Gökay reassigned CAMEL-26376:
------------------------------------
Assignee: Serdar Gökay
> 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
> Assignee: Serdar Gökay
> Priority: Minor
>
> 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)
