Replies: 2 comments 1 reply
-
|
I am not a cFS maintainer, but I have a decent familiarity with the cFE internals. I have no idea what this LLM is asking about. I even clicked through to the linked project to see what it was doing and still don't understand what specifically is being asked. Maybe someone else understands better, but you'll have to be much more clear about how this URML system works for me to be able to help with the question. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @irowebbn, and fair point. Let me strip it right down. URML is a small language for stating a robot/system command as intent: you write a high-level goal, it is checked against a declared capability + safety manifest, and only if it passes does it get turned into the actual commands the system runs. The validation-before-dispatch is the whole point. For cFS the one concrete question is just this: when an external layer wants to issue commands, is the intended path to publish command messages onto the Software Bus for the relevant app to receive, or is command ingest app-specific with no common entry point? That single answer tells me whether a cFS binding is even sensible. Thanks for taking the time to look. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi cFS community,
URML (urml.dev) is a small, Apache-2.0 language for describing robot intent: it validates a request against a capability manifest and a safety envelope, then dispatches. cFS is interesting to URML as a flight-software substrate whose surface is named app commands over the software bus — the same shape URML binds for AUTOSAR and proposes for F´.
Nothing here asks cFS to adopt, host, or maintain anything. This is a request for comment.
URML binds named substrate operations to its call_program verb rather than adding a primitive. A cFS app command (app + command code + typed message) would be declared in the URML manifest as a program with a binding; URML validates the binding and args before dispatch. The cFS scheduler's cyclic timing maps onto URML's descriptive realtime block (period + watchdog, no enforcement claim).
Two real questions: (1) Is a declared program plus a command binding (app / command code / typed message) the right granularity to name a cFS command from an outside intent layer? (2) Would the command/telemetry database be the right source for those binding declarations?
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0390-cfs-outreach.md
Thanks for cFS; a generic, reusable flight-software architecture flown across so many missions is a great thing to have in the open.
Ido Yahalomi (URML, greenvh@gmail.com)
AI-assisted prose, maintainer-reviewed before posting (see VIBE.md). Human-only correspondence available on request.
Beta Was this translation helpful? Give feedback.
All reactions