OrchestraOS Specification¶

OS Features¶

This overview describes the Scarthgap baseline. The selected target, image, and enabled extensions determine the capabilities included in a device image.

Base System¶

Scarthgap capabilities¶
Capability	Scarthgap support
System and images	Linux and systemd, with command-line images and Weston/Wayland/XWayland graphical images. Documentation: Introduction to meta-orchestraos.
Supported targets	EIG-M, EIG-M-DIN, EIG-MA, and EIG-XS gateways, plus ARM64 QEMU with U-Boot or UEFI. Target configuration selects the firmware and boot flow. Documentation: Supported Targets.
Native applications and containers	Target-native Linux applications and systemd services, alongside Docker Moby and Docker Compose. Docker state is stored under `/data/docker`. Documentation: Base Software and Applications.
Storage and configuration	Read-only rootfs policy, LVM-backed system and application slots, and shared persistent data. Rootfs-on-LVM images use a persistent `/etc` overlay backed by `/data`. Documentation: Storage and System Updates.
Boot and provisioning	Initramfs prepares and activates the storage layout. Hardened EIG U-Boot configurations restrict saved-environment overrides. QEMU UEFI images provide installer ISO output. Documentation: Boot and Provisioning.
System updates	Signed RAUC bundles and A/B boot, rootfs, and application slot groups, with hawkBit delivery integration. The target’s boot selection and retry mechanisms support fallback; the deployment supplies its health policy. Documentation: RAUC Update Flow.
Networking and remote access	NetworkManager for wired, Wi-Fi, and cellular connectivity, WireGuard tools, and OpenSSH. Hardware availability, network settings, credentials, and access policy are configured for the deployment. Documentation: Network Connectivity.
Device security	TPM2 tools and PKCS#11 interfaces, plus BSP-selected HAB4/AHAB authenticated boot on supported EIG targets. Key provisioning and device security state determine the protection enforced in production. Documentation: OrchestraOS Security Architecture.
Logging and metrics	Fluent Bit for log collection and forwarding, and Telegraf for metrics. Collection settings, authenticated outputs, and service endpoints are supplied by the deployment. Documentation: Logging and Metrics Configuration.
Software inventory and vulnerability reports	The common KAS configuration enables image-specific CycloneDX SBOM/VEX output and CVE checking. SPDX inventories are available when enabled by the selected build configuration. Documentation: Software Inventory and Vulnerability Reports.
Orchestra Manager integration	Runtime tools for enrollment, remote execution, container operations, telemetry, and updates. The deployment supplies enrollment assets, device identity, trust material, and endpoint configuration. Documentation: Orchestra Manager Platform Integration.

Optional Extensions¶

Optional Scarthgap extensions¶
Extension	Capabilities and scope
Extended Security	Device-bound encryption for rootfs, application, and data volumes, with hardware-backed key protection on supported EIG gateways. Boot filesystems and the provisioning partition remain outside encrypted LVM.
NetHSM Signing	Build-time integration with Nitrokey NetHSM for signing boot artifacts and RAUC update bundles using keys held by an external HSM.
Machine Learning	NXP inference-stack integration for supported i.MX8M Plus targets, with EIG-M as the reference configuration. TensorFlow Lite acceleration through the OpenVX delegate depends on the runtime and supported model operators.

Extensions are licensed separately. Their implementing layers document detailed configuration and integration. Contact sales@cthings.co for access and licensing.

Release policy and source distribution are described in OrchestraOS Releases and Maintenance.

Support Models¶

Support model	CTHINGS.CO	Customer
Fully outsourced	CTHINGS.CO provides the BSP and image generation infrastructure, Customer’s application integration, logistics, and delivery.	Customer provides the application to be integrated. Provisioning information, certificates, keys, etc. are provided by the Customer, or provisioning can be performed using the Customer’s application on boot (preferred).
BSP handover	CTHINGS.CO provides the BSP in the form of shared code with placeholder software and provides the necessary tooling for the Customer to build an image in the Customer’s infrastructure. CTHINGS.CO manufactures the final gateway using images provided by the Customer and handles logistics.	Customer fills in the placeholder software delivered by CTHINGS.CO and generates an image. Images are handed over to CTHINGS.CO for final manufacturing along with the relevant provisioning information, certificates, keys, etc. Alternatively, provisioning can be performed using the Customer’s application on boot (preferred).
Layers handover	CTHINGS.CO shares meta-layers with the Customer. Some of them might be public. Relevant on-demand features are implemented and shared through an isolated Git service.	BSP build and Customer application integration are performed on the Customer’s side. CTHINGS.CO only handles manufacturing and logistics. The Customer must provide the final image and relevant provisioning information. Alternatively, provisioning can be performed using the Customer’s application on boot (preferred).

Support model

CTHINGS.CO

Customer

Fully outsourced

CTHINGS.CO provides the BSP and image generation infrastructure, Customer’s application integration, logistics, and delivery.

Customer provides the application to be integrated. Provisioning information, certificates, keys, etc. are provided by the Customer, or provisioning can be performed using the Customer’s application on boot (preferred).

BSP handover

CTHINGS.CO provides the BSP in the form of shared code with placeholder software and provides the necessary tooling for the Customer to build an image in the Customer’s infrastructure.

CTHINGS.CO manufactures the final gateway using images provided by the Customer and handles logistics.

Customer fills in the placeholder software delivered by CTHINGS.CO and generates an image.

Images are handed over to CTHINGS.CO for final manufacturing along with the relevant provisioning information, certificates, keys, etc. Alternatively, provisioning can be performed using the Customer’s application on boot (preferred).

Layers handover

CTHINGS.CO shares meta-layers with the Customer. Some of them might be public. Relevant on-demand features are implemented and shared through an isolated Git service.

BSP build and Customer application integration are performed on the Customer’s side. CTHINGS.CO only handles manufacturing and logistics.

The Customer must provide the final image and relevant provisioning information. Alternatively, provisioning can be performed using the Customer’s application on boot (preferred).