Omnistack
Detail

How an application reaches the hardware

Six stages, the five layers they run on, one system spread across several boards, and the targets we ship to.

技术细节

一个应用是怎么走到硬件上的

六个阶段、它们所跑的五层底座、一套系统铺到多块板子,以及我们交付的目标平台。

What it does

Requirement what you want built Architecture scenarios · devices · contracts Generate signed app packages Simulate before any hardware Deploy to the physical board Verify on the real panel evidence flows back: component tree · software frames · anything still unproven Every stage leaves behind something the next one can check — including the last one.
◧
Authoring

Design the system first

Before a line of UI exists, the work is a framework: which scenarios, which devices, which apps, and which contract binds them. The platform each capability lands on is a decision with stated criteria, not a default.

◇
Building

Apps carry no native code

An application is a signed, data-only package — UI, manifest, assets, localisation. Every effect it has on the outside world goes through a declared contract, so one bad app cannot take the system down.

◉
Verification

The board answers for itself

The panel is read and clicked directly. No replayed recording, no screenshot comparison — the software frame captured beside each assertion is the same observation that satisfied the assertion.

它能做什么

需求 你要造的东西 架构 场景 · 设备 · 契约 生成 签名的应用包 模拟 在碰硬件之前 部署 送到真实板子 验证 在真实屏幕上 证据回流:组件树 · 软件帧 · 尚未证明的部分 每一环都留下下一环能检查的东西——最后一环也是。
◧
设计

先把系统设计出来

在还没有一行界面之前,产出的是一个框架:哪些场景、哪些设备、哪些应用、什么契约把它们绑在一起。每个能力落在哪个平台,都是有判据的决定,不是默认继承。

◇
构建

应用不带原生代码

一个应用是签名的、纯数据的包——界面、清单、资源、多语言。它对外的每一个作用都经过声明过的契约,所以一个坏应用拖不垮整套系统。

◉
验证

板子自己作证

面板被直接读取和点击。没有回放、没有截图比对——那张和断言取自同一次观测的软件帧,就是证据本身。

What runs underneath

Omnistack apps run on AppOS, a five-layer embedded operating system that builds, releases, deploys and rolls back on its own. The layers are not a diagram — a package that crosses one is refused at build time.

Application data-only packages: no native code, no scripts, no device nodes typed callbacks · capability requests Framework lifecycle · permissions · resource arbitration · IPC · UI toolkit typed platform API System service the privileged owner of anything live hardware abstraction Device service hardware providers and backends vendor API Vendor BSP kernel · drivers · vendor libraries
Crossing a layer is a build failure, not a code review comment.
Isolation

A third-party app cannot reach the hardware, the kernel, or another app's state. Everything it can do is something it declared.

Lifecycle

Releases are signed, deployed atomically, health-checked, and rolled back to the previous one automatically if a candidate fails to come up.

Bounded

Logs, resource arbitration and call lifecycles are all bounded. A misbehaving component degrades instead of taking the panel down.

底下跑的是什么

Omnistack 的应用跑在 AppOS 上——一个可独立构建、发布、部署和回滚的五层嵌入式操作系统。 这五层不是一张示意图:越层的包在构建期就会被拒绝。

应用层 纯数据包:无原生代码、无脚本、无设备节点 类型化回调 · 能力申请 框架层 生命周期 · 权限 · 资源仲裁 · 进程间通信 · 界面工具包 类型化平台接口 系统服务层 一切"活的东西"的特权所有者 硬件抽象 设备服务层 硬件 Provider 与后端 厂商接口 厂商 BSP 内核 · 驱动 · 厂商运行库
越层不是代码评审里的一条意见,是构建失败。
隔离

第三方应用碰不到硬件、碰不到内核、也读不到别的应用的状态。它能做的每一件事,都是它声明过的。

生命周期

Release 是签名的、原子部署的、带健康检查的;候选版本起不来时自动回滚到上一个。

有界

日志、资源仲裁、呼叫生命周期全都有上界。一个出问题的组件会降级,而不是把面板拖垮。

One system, several boards

Systems that span more than one device are where embedded projects actually get hard. Omnistack treats each board as a declared cell of a matrix — what it has, what it does not, and which capabilities must never cross between them — instead of discovering that at integration time.

Board A — bedside product profile · HAL profile · broker policy declares what it does not have, and why a build-time test forbids the other board's routes rows · columns · gaps — all declared up front Board B — room door product profile · HAL profile · broker policy different screen geometry, different timeouts missing peripherals are declared, never faked one AppOS underneath, no bleed across the boundary capability bleed
Two boards, one AppOS. A profile is both a capability declaration and an isolation boundary.

Every claim a board makes is checkable, because each board's profile states which domains it has, which it lacks and the reason, and which routes belong to it alone. Integration then becomes a sweep over a known matrix rather than a search through an unknown one.

一套系统,多块板子

跨多设备的系统才是嵌入式项目真正会卡住的地方。Omnistack 把每块板子当作矩阵里一个 声明出来的格子——它有什么、它没有什么、哪些能力绝不允许跨过去—— 而不是等到联调时才发现。

板 A — 床旁 产品 profile · HAL profile · broker policy 声明自己没有什么,以及为什么 构建期测试禁止它携带另一块板的路线 行 · 列 · 缺口——全部事先声明 板 B — 病房门 产品 profile · HAL profile · broker policy 屏幕几何不同、超时不同 缺的外围设备是声明出来的,不是假装有 底下是同一套 AppOS,边界不串格 能力串格
两块板,一套 AppOS。profile 既是能力的声明,也是隔离的边界。

板子说出的每一句都可以被核对:它的 profile 写明有哪些域、缺哪些域、原因是什么、 哪些路线只属于它。于是联调变成在一张已知矩阵上遍历,而不是在一片未知里搜索。

Targets

PLC indoor unit

NX5

European two-line indoor unit. Armel target, cross-compiled and deployed over a signed release.

Bedside / call

NX1 Cedar

Bedside call unit, sharing one AppOS with the room door and declaring a disjoint capability set.

Simulation

Desktop simulator

Runs the real application package before any hardware is involved, including touch and frame assertions.

Handheld

Android

Flutter targets built, installed and screenshotted on device when the deliverable is a handset app.

Figures on this page come from measurements taken on physical hardware. What was never tested is not claimed here.

支持的平台

PLC 室内机

NX5

欧洲两线室内机。armel 目标,交叉编译,通过签名 Release 部署。

床旁 / 呼叫

NX1 Cedar

床旁呼叫单元,与病房门共用同一套 AppOS,并声明互不相交的能力集。

模拟

桌面模拟器

在碰任何硬件之前运行真实的应用包,支持触摸与帧断言。

手持

Android

交付物是手机应用时,用 Flutter 构建、装机并在真机上截图核对。