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