Architecture Research

This page is where the Foundation publishes research on the architecture of the EmbeddedOS platform as a whole: how the kernel, the IPC layer, the storage layer, the boot sequence and the surrounding services fit together, and what each of them is allowed to assume about the others. A single subsystem can be studied in isolation, but a system is built from its boundaries, and this category is where those boundaries are examined.

Nothing is filed here yet. Architecture work currently appears in the Technical Reports category and in the master design document for the platform. This page exists so that when architecture-level write-ups do appear, they have a home that is distinct from subsystem documentation and design notes.

Architecture research at the Foundation means asking questions like these: what may the boot loader assume about the kernel image it hands off to; what may the kernel assume about the behaviour of the IPC transport; what does the storage layer guarantee, and to whom, when power is lost mid-write. These are not implementation details. They are the contracts that make the whole system predictable, and they are exactly the place where reasoning about correctness has to live.

A write-up in this category starts from a contract — a stated set of assumptions and guarantees — and works outward. The implementation that satisfies the contract lives in the repositories on GitHub; the write-up explains why the contract is shaped the way it is, what alternatives were considered, and what breaks if an assumption is violated.

The Foundation's research programme covers areas like health monitoring hardware and avionics, where a failure of the platform is not an inconvenience but a hazard. In safety-critical engineering, the standard practice is to argue explicitly about why a system is safe to use. That argument depends on assumptions holding: the watchdog fires, the redundant path takes over, the corrupted state is detected. Architecture research is where those assumptions are collected, written down and examined.

The blunt version of this is that assumptions are where bugs live. A subsystem can be correct against its own specification and still fail the system if two specifications disagree about what the other promises. Writing the contracts down does not remove that risk, but it turns silent disagreements into visible ones, which is the first step toward fixing them.

Technical Reports document subsystems: what a component does, how it was built, what was measured. This category covers the whole and its contracts: how the subsystems combine, what the composition assumes, and what the platform's design argues overall. If Technical Reports are the chapters, the architecture research is the document structure — the argument that the chapters belong together and what holds them up.

In practice the two will reference each other. An architecture write-up will point at the Technical Reports for the subsystems it builds on, and Technical Reports will point here when a design decision only makes sense in the context of a system-level contract.

Architecture write-ups will state their assumptions explicitly rather than leaving them implicit. They will include diagrams of the layer structure and the data flows, design rationale that explains why the chosen contract was preferred over alternatives, and a discussion of failure modes: what happens when an assumption is violated, and how the system detects or contains the violation.

Each write-up will be reviewed by the project maintainers before publication, and all of it will be published under the Foundation's name with the source material available in the GitHub repositories, so readers can check the reasoning against the actual code.

Until write-ups appear here, the best places to follow the architecture work are the Technical Reports page and the master design document, which together show how the platform's design is evolving. The implementation itself is public: the eos repository on GitHub contains the kernel, and the surrounding repositories contain the boot loader, build tooling and services.

If you are working on a system-level design question and want to discuss it with the maintainers, the contact page has the details, and research collaboration questions can go to partners@embeddedos.org.