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.
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.