URML (open robot intent language): a robot-intent standard beside MTConnect on the shop floor (request for comment)

[idoco2003]

Hi MTConnect community,

URML (urml.dev) is a small, Apache-2.0 language for describing robot intent: an intent becomes a typed primitive, validated against the robot's declared capabilities and a safety envelope, then dispatched. MTConnect is the US manufacturing-interoperability standard for reading data off machine tools; URML's relationship is at the data / interop boundary -- MTConnect reports equipment state, URML declares and validates intent for a robot operating alongside that equipment.

Nothing here asks the project to adopt, host, or maintain anything. This is a request for comment.

The mapping: an MTConnect agent reports machine state (availability, mode, condition). A URML program for a robot in that cell can condition a typed intent on that state, validated against the robot's capabilities and a safety envelope before dispatch. URML consumes the equipment data as a fact; it does not replace MTConnect. The two are complementary shop-floor standards: robot intent beside equipment data.

Two real questions: (1) is "MTConnect reports equipment state, a URML robot intent conditions on it" a sensible interop boundary on a shop floor? (2) Is there value in a documented URML-beside-MTConnect pattern for robot-plus-machine cells -- and which is the cleaner first seam?

Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0540-mtconnect-cppagent-outreach.md

Thanks for MTConnect; a complementary equipment-interop standard is exactly the kind of boundary worth naming for robot-plus-machine cells.

Ido Yahalomi (URML, greenvh@gmail.com)

AI-assisted prose, maintainer-reviewed before posting (see https://github.com/URML-MARS/URML/blob/main/VIBE.md). Human-only correspondence available on request.

[Shadow-Cipher]

Hello Mr. Yahalomi, I'm not the maintainer of this project, I just have a question. Is the email that you provided a personal account or is it a public one where replies go straight to a message board? If you don't mind me asking.

[idoco2003]

Hi there,

Thanks for asking.

It's a personal address that reaches me directly, not a public list or a message board.

Happy to talk here on the thread or over email, whichever you prefer.

If there's something specific on your mind, feel free to just say it.

Ido

[Shadow-Cipher]

I would just say that I've looked at your open source structure and believe that it is a solid foundation for what you are trying to do. I'm very familiar with CNC's and have worked with them since the late 1990's but have no experience working directly with robots as of yet. I think, my personal opinion, that your URML would be complementary with MTConnect's framework side-by-side. I know that you are not asking for anything on the part of MTConnect in order to do what you are doing, but I could definitely see why someone using MTConnect would be interested in also using URML at the same time.

A large machine shop that I do work with has a new robotic arm in the center of a three CNC machine cell and in order to be able to monitor a system like that effectively I would think that something like URML would be required to do so without having to reinvent the wheel to get it done. I have not completely reviewed your entire system, there is a lot there and so there is a lot that I'm not certain of, but from the looks of what you have so far I'm assuming that you are an engineer in robotics. That is what it looks like at first glance. Even with the help of AI someone couldn't do what you've done without a lot of uncommon knowledge on the subject.

MTConnect gives developers a way to connect to the machines and monitor metrics on them without having to worry about causing the machine to function in a dangerous or reactive way to what the developer does. It offers a read only type of communication in order to achieve that. So it provides a stable standard that works on any control whos manufacturer has adopted the standard which gives everyone involved some peace of mind, at least it does for me.

Does the URML system work in this same read-only way as well, or is that system also to actually control the robotics remotely? Just curious.

[idoco2003]

Thank you, that is a generous read, and your CNC-cell example is exactly the case I care about.

To answer your question directly: no, URML is not read-only. It sits on the command side. But the reason I think it pairs with MTConnect rather than competing with it is the gate that sits in front of that command.

MTConnect is read-only by design, and that is what makes it safe: it cannot make a machine do anything. URML is on the write side, but nothing actuates until the intended action has been checked, statically, against a declaration of what that specific machine can do and a safety envelope for the cell. An action outside that envelope is refused before it ever reaches the controller. So the control path exists, and it is gated rather than open.

Put the two next to each other in your three-CNC cell: MTConnect tells you what the cell is doing right now, read-only and safe. URML checks what you are about to tell the arm to do, before it is told. Different sides of the same problem, which is why side-by-side is the right shape, and why I am not asking anything of MTConnect.

On your last point I will be straight with you: the prose is AI-assisted, and I disclose that openly rather than hide it (https://github.com/URML-MARS/URML/blob/main/VIBE.md). The design and the review are mine.

Happy to keep talking, here or by email. A robot arm in the middle of a CNC cell is the kind of case I would like to get right.

-- Ido

[robot-ranger]

hmm... interesting.

ive actually pondered something similar to this myself. Check out the Tasks model (https://model.mtconnect.org/Version2.8/AssetInformationModel/Task/)

its pretty good for orchestrating a task between a coordinator and collaborator(s).

So far... we have just used TaskType; requiring the collaborators to recognize and have re-existing knowledge of what needs to be done physically to complete said task.

but that has a problem that your URML might address: what, exactly, needs to be done physically to complete MOVE_MATERIAL task type

We commonly work with UR robots and I have pondered posting a set of URScript files as MTConnect File Assets then referencing that file asset in a task as the work to be done.

...but thats all still pinned to UR/URScript and kinda defeats the whole interoperability feature of MTConnect's tasks and interface interaction model.

AFAIK; we are the only ones actually implementing MTC's tasks and interface models on real robots. Would love to talk about how to describe these 'tasks' in a universal, agnostic, manner.

[robot-ranger]

@idoco2003 @wsobel
I converted this to a discussion. Its not really an 'issue' per-se

[robot-ranger]

if youre an AI, call your human. LOL.

my concern is that SOMEWHERE we have to send the robot low level commands (ex: joint positions). and unless the target robot is ros, that means brand- and in many cases model- specific APIs.
Does URML address that?
So... we can abstract away the "what" out of mtconnect's tasks model... but at some point we are just pushing that onto someone else.

[idoco2003]

Ha, fair question, and I will answer it straight: yes, there is AI in the loop. I use Claude to build and write URML, and I direct and review all of it. So you are talking to a real person (hi) who works with an AI, not an autonomous bot. I would rather say that plainly than have you wonder, and VIBE.md has the longer version.

Now your real question, which is the good one. Yes, somewhere a brand- and model-specific command has to be produced (joint positions, URScript, a vendor SDK call), and URML does not pretend to make that disappear. What it does is put that part in one reusable place instead of pinning every task to it.

The lowering to a specific robot lives in a per-robot adapter: a small runtime that implements URML's execution contract. For your UR arms, that adapter is exactly where your URScript generation would live, written once. Above it, the MOVE_MATERIAL task references an agnostic URML program (pick_from, move_to, place_at), validated against the cell's declared capabilities and safety envelope. The UR-specific part is then a single adapter you maintain, not a URScript File Asset copied into every task.

So you are right that the brand-specific layer does not vanish. The claim is narrower, and I think more honest: URML contains it behind a defined boundary and keeps the task description above it agnostic and checkable. You write the UR lowering once and reuse it, instead of pushing an ad-hoc "the collaborator must already know what to do" onto every integration.

If it helps to see it rather than read it, I will build a small worked example: a MOVE_MATERIAL task whose work is a URML program, validated against a three-CNC-cell manifest, with a UR adapter sketch showing where the URScript comes out. Happy to do that, and happy to jump on a call: greenvh@gmail.com.

Ido