Labinetix
Living. Kept current and swept at every release.
An execution platform: define → analyze → compile → deploy → execute models on embedded control hardware, behind one stable ABI — one binary interface that does not move under the code already running on a device.
A control model — a filter, a state-space system, a supervisory rule — usually starts life on an engineer’s workstation and ends it as hand-written code on a controller, with nothing but a changelog connecting the two. Labinetix closes that gap. The model is written down once, as data. Everything that reaches the hardware is derived from that one description. And what the device actually did can be put side by side with what was predicted before it shipped.
What it is not
Not an operating system. On the controller, Labinetix is a shared library that an existing control runtime loads and calls. It runs inside that runtime’s cycle, on the schedule the runtime decides, and hands control back on time.
Not a modelling tool. Models come from wherever you already build them. Labinetix takes the description, not the tool.
Not a cloud service. Everything here runs on a workstation you own and on the controller in front of you.
The six stages
Everything the platform does is one of six verbs, and the command line has one subcommand per
verb, so the tool grows leaves and never re-roots. The sixth is observe, and it is the one
most tools leave out: what comes back off a device matters as much as what went out to it.
| Stage | What happens |
|---|---|
| define | The model, its parameters and its interface are written down as data, in a store that reads back exactly what was put in |
| analyze | The consequences are worked out on the workstation — behaviour, sizes, timing — before anything is built |
| build | The definition is compiled into the artifact a controller can load |
| ship | That artifact is installed on a device, with a plan produced and inspected first |
| run | The controller executes it inside its own control cycle |
| observe | What the device actually did is recorded — and compared against what analyze predicted |
The loop closes: observe feeds back into analyze, and the comparison is done by the same
code that made the prediction. “It behaves as designed” is a result, not an opinion.
What runs where
On the workstation live the tools: the definition store, the analyses, the compilers, the deployment planner, the reader for evidence that comes back. They may be as large and as convenient as they like.
On the device lives as little as possible: the numerical kernels, a thin runtime that calls them, and one small library at the boundary where the control runtime calls in. Nothing that exists only for a developer’s convenience is allowed near the hardware — and that is a rule the build refuses to let anyone break, not a habit someone has to remember.
What the platform holds to
Seven promises. They are the reason the rest can be trusted.
- Nothing developer-only reaches the device. Code that ships to hardware cannot depend on code that exists only on a workstation.
- The maths is separate, and pure. The numerical kernels have no operating system beneath them, no memory to allocate, no files to read and no knowledge of the platform calling them. That is why the same kernel can be exercised on a laptop and trusted on a controller.
- Code that must trust the outside world is a short, named list. Where the platform has to accept memory it did not allocate, every such place is written down with its reason. There is no unlisted place that nobody remembers.
- The parts that name things do not compute things. Numerics live in the kernels; the layer that gives values names and shapes does nothing but that.
- The control loop holds no surprises. Everything that could take an unpredictable amount of time — parsing, validating, resolving, reserving memory — happens once at start-up. Inside the cycle there is arithmetic and nothing else.
- What is generated is never edited. Files derived from a model definition are written by the generator and by nothing else, and every artifact refers to a definition by its content, never by a name that could quietly come to mean something different.
- Facts learned from real hardware are not tidied away. A behaviour proven on a device — an interface layout, a system library version a controller pins us to, an activation sequence — changes only for a written-down reason, and only with another run on real hardware.
Where this stands today
Early, and this page says so plainly.
The source tree builds and its tests pass on every change. The command line exists and all six
stages have their place in it; two of them, analyze and run, have no library behind them
yet and say so when you invoke them instead of pretending. Model definitions, their generated
views and the deployment planner are real and exercised. Several controller platforms are
described in the platform library, and one of them has a committed record from a real device
behind that description.
No release has been cut, and there is nothing to download yet.
Nothing anywhere in this documentation is written in the present tense unless it exists. A sentence that describes unbuilt capability as though it were running is treated as a bug and fixed like one.
Start here
- Getting started — about five minutes on your own machine: build the command line, read a model out of the definition store, read a target’s description, produce a deployment plan without touching a device, and hear the two unwired stages say so. Every command on that page is run automatically on every change to the platform, so it cannot describe a tool that does not exist.
- CLI reference — every command, option and argument, walked off the command line itself rather than written by hand.
Licence
Not yet declared.