Embedded DeviceOps Suite
Tempo2Market combines customer hardware, hex-browser, Yocto Linux and ttmdaemon with manufacturing workflows and Fleet Warden operations so embedded products can be built, shipped, updated and supported.
Your team owns the product USP. Tempo2Market owns the repeatable infrastructure around it.
Tempo2Market supplies the lifecycle infrastructure around your embedded application.
Platform overview
Tempo2Market separates the customer value from the infrastructure that every connected device still needs. The OEM owns the application and user experience. The platform supplies the repeatable lifecycle around it.
Every device leaves production with identity, branding and a validated baseline image.
The device runs the hardware, Linux, security and app runtime needed for field operation.
Fleetwarden operates devices after shipment with rollout control and remote support.
Next step
Bring your hardware, application idea or production flow. We map the shortest path from prototype to maintainable connected product.
Device identity, signed updates, OP-TEE-backed secure boot, mTLS-secured communication and governed rollouts are part of the platform instead of late project add-ons.
Tempo2Market fits OEM products that need a maintained device platform, not just an app prototype.
Product description and technical documentation
Full-stack infrastructure for connected embedded products. HTML version derived from the LaTeX product description.
Tempo2Market (T2M) is an integrated embedded platform that accelerates product development by providing a ready-made hardware, Linux, security, runtime, cloud, and provisioning ecosystem for connected embedded devices. It combines a production-ready device platform with a long-lifecycle Yocto-based Linux foundation, a stable on-device middleware (ttmdaemon), and a lifecycle cloud (fleetwarden) for OTA, telemetry, and LIVE service. This end-to-end stack removes non-differentiating engineering work—kernel/BSP maintenance, security hardening, update rollouts, fleet tooling, and factory identity onboarding—so OEMs can focus on their core competence: their application and product value. Tempo2Market emphasizes secure boot and cryptographic device identities, fail-safe update chains, robust rollout governance, and practical remote diagnostics. The result is a reusable platform layer for embedded systems—comparable in intent to an “Android for embedded”, but designed for industrial lifecycle control, maintainability, and security-by-design. OEMs innovate on their product, not reinvent the infrastructure.
Watch the 90-second video pitch
This document describes Tempo2Market as a product stack and as a reference architecture. It is written for technically interested OEM stakeholders (embedded, cloud, security, operations). The document focuses on capabilities and interfaces while concrete project choices (hardware variants, rollout policies, privacy modes, on-prem options) are package- and customer-dependent.
fleetwarden (OTA, telemetry/logs, LIVE service, policies).Tempo2Market’s embedded hardware domain is the field-facing foundation of the platform. It is designed to be secure, updateable, and maintainable over long product lifecycles, while providing a stable base for on-device applications.
hexBLUE: reference Single-board-computerThe role of hexBLUE within Tempo2Market is to serve as the reference single-board computer. It can be used as-is or as a baseline for customer-specific variants, including optional display-oriented configurations.
hexBLUE SBC (PCB render): Tempo2Market reference hardware platform for edge gateways and embedded devices.For Tempo2Market customers, the key is shipping the product USP quickly while keeping platform risk and lifecycle cost low. hexBLUE supports this with a stable hardware core (SoC, RAM, PMIC, eMMC) and a peripheral layer that is designed to be adapted. Industrial-relevant interfaces are pre-routed and validated, reducing iteration cycles when integrating sensors, actuators, or project-specific peripherals.
Hardware variants are typically created through connector tailoring and BOM options—for example enabling/disabling Power-over-Ethernet, or leaving optional components (e.g., Wi-Fi) unpopulated for cost-optimized small series.
Unlike traditional SoM architectures (complex, high-layer module plus a separate carrier/baseboard), hexBLUE is structured so the core already fits into a compact, low-layer PCB design. This makes it practical to place customer-specific peripherals on the same board instead of relying on an additional baseboard. As a result, variants can avoid expensive board-to-board connectors and extra assembly steps, reducing cost, complexity, and field failure points. Because the platform baseline stays consistent, customer variants remain updateable and maintainable over long lifecycles with the same Tempo2Market software stack and operations tooling.
hexIO: PLC-style I/O expansion (in development)hexIO is designed as a PLC-style industrial I/O expansion for control cabinets. In many modern cabinet systems, the HMI is already web-based and runs on a panel computer that has enough compute for the application logic—but it is not built for direct 24 V field wiring. hexIO closes this gap by providing the cabinet-facing I/O layer, while hexBLUE (optionally with display) remains the central compute and HMI platform.
Instead of bringing industrial wiring to the display unit, hexIO is intended to sit close to the 24 V sensors/actuators in the cabinet and connect to hexBLUE via a simple link. Target connectivity options include RS485 and Ethernet, enabling flexible placement and topologies depending on cabinet layout, EMC constraints, and wiring practices. This separation keeps the UI device lean, reduces harness complexity, and supports scalable installations.
By combining hexBLUE (compute + UI + Tempo2Market runtime) with hexIO (industrial I/O), Tempo2Market targets a cost-optimized and maintainable alternative to classic “PLC + panel + integration glue” architectures. The goal is fewer devices, less duplicated compute, and faster commissioning—while keeping the full lifecycle benefits of Tempo2Market: governed updates, security-by-design, and remote operations support over many years.
hexExtensionNFC: NFC and RGB extension for access control
hexExtensionNFC (hexNFC) (PCB render): NFC identification and RGB status/UX extension for access control systems, connected to hexBLUE via I2C.hexExtensionNFC adds a proven NFC identification front-end and clear local user feedback (RGB LEDs) to Tempo2Market-based devices. It targets access control and entry systems (e.g., terminals, turnstile controllers, and kiosk-style check-in points) where reliable credential capture and unambiguous status indication are essential for user flow and supportability. For OEMs, the value is a reusable extension that avoids building and validating an NFC and UX subsystem from scratch.
The board integrates an NFC subsystem and multiple RGB LEDs for high-visibility device feedback. An on-board LED controller supports PWM-based patterns and effects, enabling consistent, product-grade status signaling (e.g., ready/standby, credential accepted/denied, processing, error).
Both the NFC subsystem and the LED controller are connected to hexBLUE via I2C. Using a simple internal bus keeps integration lean and cost-efficient, while remaining well-suited for short internal wiring in industrial enclosures. The result is a compact access-control building block that can be integrated into customer-specific housings.
hexExtensionNFC is supported directly in the Tempo2Market device platform: the required drivers and integration are part of the BSP, so OEMs do not need to implement low-level NFC bring-up. The NFC reader and the LED controller are exposed through ttmdaemon as stable application interfaces—via a documented REST API, a local library, and D-Bus. This allows customer applications to consume NFC events and drive user feedback at an abstract level (e.g., “card presented”, “grant/deny”, “set status pattern”) without depending on hardware details. As a result, the OEM remains focused on the product USP (access logic, user flow, backend integration), while Tempo2Market provides the maintained platform layer that keeps the device secure, updateable, and supportable over the lifecycle.
hexBLUE with hexExtensionNFC in an enclosure connected to a turnstile for an access control system.In real-world products, the core device often needs to interact with additional application-specific components such as sensors, actuators, or control elements. Depending on the use case, this can include relays, signal lines, or dedicated interfaces that are not part of a generic platform.
Figure 4 illustrates such a scenario: besides NFC-based identification, the access control system must actively control a physical turnstile via a relay or actuator. For these cases, Tempo2Market supports customer-specific adapter boards and peripheral extensions, enabling direct integration of application-specific hardware while preserving a clean, maintainable platform architecture.
Tempo2Market’s embedded software stack is built for long-lifecycle connected devices: it keeps the OEM’s application logic independent from low-level platform concerns while staying secure, patchable, and updateable over years. The stack is based on an OE/Yocto Linux distribution maintained by hexDEV, a hardened boot and update architecture, and an on-device runtime (ttmdaemon) that provides stable APIs for applications and optional cloud/fleet operations.
meta-hexdev)Tempo2Market uses OE/Yocto to build a reproducible, purpose-built Linux distribution where the full software bill of materials is explicit and maintainable. A key design choice is a mainline-oriented kernel strategy: instead of freezing a vendor BSP for years, Tempo2Market is designed so kernel and userland security fixes remain feasible throughout the product lifetime. The distribution is intentionally slim—only required kernel options and user-space components are enabled—which reduces attack surface and lowers long-term maintenance cost.
The platform integration is captured in the meta-hexdev layer, which bundles the Tempo2Market runtime and base services (including ttmdaemon and standard apps such as the kiosk browser on display devices). Hardware support lives in dedicated board layers, and OEMs typically add a project layer for product-specific packages, configuration, and branding. This separation preserves a clean upgrade path: the platform can evolve without forcing rewrites of the OEM’s application.
The Tempo2Market Yocto layer set (including pinned revisions) is published as a manifest repository:
git clone git://hexdev.de/manifestEmbedded devices only stay valuable if they remain patchable. Tempo2Market therefore treats updateability and security as built-in system properties. The boot chain is designed to start only trusted, signed images and to establish a secure foundation early (including protected execution via OP-TEE where supported). A redundant A/B system layout enables fail-safe updates: new software is installed to the inactive slot, activated by a controlled boot switch, and can be rolled back if a deployment fails. In practice, this turns security and maintenance into a repeatable process rather than a risky one-off project phase.
The platform also separates immutable system software from device-specific state. The root file system can remain read-only and reproducible, while persistent data (configuration, application state, logs, UI assets) lives in a dedicated persistency partition. This reduces update-induced failures, prevents configuration drift across updates, and makes field behavior predictable.
Finally, the security model extends beyond the device: each unit is provisioned with a cryptographic identity during manufacturing (anchored in protected execution where supported) and uses authenticated, encrypted communication to Tempo2Market cloud services (mutual TLS to fleetwarden). Together with signed update artifacts, this creates an end-to-end chain of trust from factory to fleet operations.
ttmdaemon: on-device application server and API anchorttmdaemon is the stable integration point between application, device, and cloud. It starts during boot, uses the device’s provisioned identity (anchored in protected execution where supported) to establish an authenticated cloud connection when fleet operations are enabled, and launches and supervises on-device applications (for display devices, typically the kiosk browser). For OEM teams, this is the key architectural advantage: the product app talks to a consistent API, while Tempo2Market absorbs the complexity of drivers, security constraints, update mechanics, and fleet integration.
Instead of each project reinventing device configuration, telemetry collection, and remote support workflows, ttmdaemon provides stable concepts that scale from prototypes to fleets:
systemd, suitable for scripts and lightweight services. In combination with fleet operations, this enables controlled remote diagnostics and support workflows without ad-hoc permanent access patterns.ttmdaemon adds security measures (e.g., protections against cross-site request forgery and a same-device policy for API access). UIs can be deployed via the persistency partition for small fleets or shipped as part of signed update bundles for larger rollouts.In short: OEMs build their USP on top of stable interfaces, while Tempo2Market keeps the underlying platform secure, updateable, and operable for years.
Tempo2Market’s cloud services are provided through fleetwarden, hexDEV’s lifecycle cloud for connected embedded devices. It is the control plane that keeps devices updateable and supportable in the field. The central design principle is: devices are born with a trusted identity in manufacturing, updates are governed and fail-safe, and configuration is done at fleet scale—without custom one-off scripts.
Once a device is deployed in the field, it can no longer be assumed trustworthy by default—physical access and supply-chain risks have to be considered. Tempo2Market therefore establishes the root of trust in a controlled environment: manufacturing.
During production, a physically local hexDEV provisioning server is used by the OEM to provision each device and establish its cryptographic identity and secure boot baseline. The device identity is anchored in protected execution (OP-TEE), the root secret material is generated and stored such that it cannot leave the secure world. This creates a practical chain of trust: the OEM provisions and signs devices in the factory, and fleetwarden can trust devices because it trusts the OEM’s provisioning process (the hexDEV provisioning server).
With the factory provisioned identity, devices authenticate to fleetwarden using mutual TLS (mTLS). This ensures that fleetwarden knows it is talking to an authentic device, and the device knows it is talking to the authentic fleetwarden service. The resulting secure channel is the foundation for lifecycle operations such as configuration, updates, telemetry uploads, and LIVE support.
Tempo2Market delivers updates as signed bundle files. On the device, the operating system runs from a read-only SquashFS partition with an A/B layout. When a bundle is deployed, it updates the inactive partition (A or B). After a controlled reboot, the device switches to the updated partition. This design provides a robust and repeatable update mechanism suitable for long lifecycle devices.
In fleetwarden, operators upload bundles and create rollout plans. Devices are organized into fleets and groups (for example by region, site, customer, or device type), enabling staged rollouts and controlled risk. This makes it possible to validate updates on a subset of devices first and then expand deployment in a governed way.
Tempo2Market provides Shared Values as the standard configuration mechanism across devices. Shared Values are managed centrally in fleetwarden and consumed on-device via ttmdaemon. This turns configuration into a repeatable, auditable, fleet-wide operation rather than a device-by-device manual process.
Typical configuration use cases include:
hex-browser (URLs, kiosk behavior, branding),fleetwarden provides a web dashboard where operators manage their fleets. Devices are listed by serial number, which is customer-dependent and assigned during factory provisioning. Operators can create device groups (e.g., by region or site) and use them for configuration and rollout targeting.
fleetwarden includes user management with role-based access control so that different responsibilities can be separated (e.g., factory users vs. operations vs. support). Two-factor authentication (2FA) is mandatory. This ensures that lifecycle control stays governed even when many users interact with the same fleet.
Tempo2Market’s Log Streams are designed primarily for data: they can carry large volumes of measurements and operational signals. Data aggregates on the embedded device, is buffered locally, and is transferred when connectivity is available. This enables building measurement systems where the actual analysis and evaluation can be performed later in the cloud, for example in an OEM-specific cloud application (see customer references such as Lehner).
fleetwarden exposes REST APIs for Shared Values and Log Streams. This allows OEMs (or hexDEV) to build custom cloud apps that integrate device configuration and measurement data into product-specific workflows, dashboards, and analysis pipelines—without rebuilding the lifecycle foundation.
LIVE service includes a browser-based VNC remote desktop. Support can see exactly what the device display shows (e.g., the HMI in hex-browser) and interact with it using pointer and input. This is designed for real-world support workflows where an operator or end user is on-site and a support engineer assists remotely.
For deeper diagnostics, LIVE service includes a web-based live terminal (typical L2 workflows) and a filesystem browser. The file browser supports uploading and downloading files to retrieve logs, provide artifacts, or perform controlled interventions. These functions are governed through fleetwarden’s access management in the web frontend (https://fleetwarden.de).
Depending on customer requirements, cloud functionality can be scoped to match privacy and operational constraints. Tempo2Market is designed so devices remain functional at the edge, while fleetwarden provides governance and lifecycle control where enabled.
Every connected embedded product starts with a great idea—and the value is the application. This is where an OEM's unique selling point lives: user experience, domain logic, and integration into the customer's process. Tempo2Market is built so teams can focus on this layer while the platform underneath (device OS, security updates, provisioning, OTA rollouts, and fleet operations) is provided as proven infrastructure.
Unlike smartphone apps, “Apps” in this context specifically denote product applications executing on the device and, where applicable, in the cloud. Tempo2Market supports both hexDEV-provided and customer-provided applications. Most products use web-based user interfaces, but native applications (Qt/QML) and small helper services are supported as well. Apps integrate through stable device APIs exposed by ttmdaemon and can be operated at scale via fleetwarden.
On-device apps run directly on the embedded system and are designed to remain functional even with intermittent connectivity. Typical patterns are:
hex-browser (kiosk/user interface),Apps use ttmdaemon for device integration (configuration via Shared Values, data via Log Streams, controlled jobs and actions), so application code stays independent from drivers and low-level system details.
hex-browser: Kiosk runtime for web user interfaceshex-browser is Tempo2Market's standard kiosk browser for display devices. It is Chromium-based and tailored for embedded UI use: predictable startup, controlled navigation, and configuration surfaces that fit fleet operations. It supports multi-touch gestures and embedded-specific kiosk behavior and is used as the default kiosk browser in Tempo2Market-based web panel deployments (e.g., TCI SmartStart/SoftwareSuite).
hex-browser can start into one or multiple predefined pages (tabs) and run in locked-down kiosk mode. Operational settings such as start pages, tab names, automatic reload, touch handling, and navigation behavior are part of the supported configuration model, so operators can adjust deployments without rebuilding firmware images. In combination with LIVE remote desktop (VNC) in fleetwarden, support can see exactly what the device shows and assist users remotely.
While web UIs are the default, Tempo2Market supports hybrid application patterns. hex-browser can be extended via Qt plugins and combined with Qt/QML components where a native UI element is useful. Plugins can be deployed as shared libraries on the device (e.g., on the persistency partition) and enabled via configuration. Public plugin examples are available at: https://github.com/ch-f/plugin-example-hex-browser.
Tempo2Market includes an on-device configuration web app (often referred to as “WebWizard”) for commissioning and service. It covers practical setup tasks such as network configuration, hex-browser start pages/tabs, kiosk behavior, branding options, updates, and device information.
Configuration can be done directly on the device or from a browser in the same LAN. For LAN-based remote configuration, the device exposes a dedicated configuration path (e.g. http://<device-ip>/Conf/) protected by a configuration PIN and a remote password (feature must be enabled on the panel). Resetting settings is intentionally only possible on the device. PIN changes/removal use a PUK provided via device management in fleetwarden.
For fleet setups, the same configuration model can also be applied centrally via fleetwarden using Shared Values—for example to mass-configure kiosk settings, deploy SSH keys for service access, or enable/disable service and developer modes.
The OEM application (the product USP) is typically implemented as a web app or a Qt/QML app that runs on the device and consumes Tempo2Market APIs. If needed, an optional custom cloud app/API can be built on top of fleetwarden REST endpoints (for example Shared Values and Log Streams) to integrate device configuration and field data into product-specific workflows.
hexDEV also provides example and project applications to accelerate adoption:
hexGym (project-specific)hexBLUE and hexNFC. Combines a web UI with a small on-device integration component that talks to a gym backend/ERP system. A companion smartphone app is in development (project dependent).nofretete (demo)hexBLUE was mounted on a DIN rail and ran the complete application and control logic, while a Beckhoff EK1100 acted purely as an EtherCAT slave/I/O coupler. This demonstrates the remote-I/O pattern (similar in role to hexIO): keep compute + HMI on the Tempo2Market device and connect cabinet I/O via a simple field link.
hexBLUE mounted on a DIN rail runs the complete application and control logic and connects via EtherCAT to a Beckhoff EK1100 I/O coupler for remote cabinet I/O—illustrating a PLC-style architecture without a dedicated PLC controller.fleetwardenfleetwarden includes built-in cloud applications for OTA rollouts and fleet configuration, including a dedicated configuration surface for hex-browser. OEMs can also build custom cloud apps on top of the same REST APIs to integrate device data and workflows into their product backend—without re-implementing lifecycle fundamentals.
Tempo2Market treats manufacturing as the start of the device lifecycle: this is where a device becomes trustworthy, identifiable, and operable at fleet scale. Instead of shipping "blank" hardware and bolting on onboarding and security later, Tempo2Market establishes the chain of trust in the factory, ships a known-good baseline image, and standardizes the steps that make devices updateable and supportable for years.
Once a device is deployed in the field, it can no longer be assumed trustworthy by default—physical access and supply-chain risks have to be considered. Tempo2Market therefore establishes the root of trust in a controlled environment: manufacturing.
Tempo2Market provides a hexDEV provisioning/branding server that is used by the OEM in production to provision each unit. This step creates a practical chain of trust: the OEM provisions and signs devices in the factory, and fleetwarden can trust devices because it trusts the OEM's provisioning process.
Typical provisioning outputs include:
fleetwarden.fleetwarden via mTLS and participate in governed lifecycle operations.Manufacturing quality depends on shipping software that is traceable and repeatable. Tempo2Market therefore aligns build, release, and operations around controlled artifacts.
The software baseline is produced as reproducible OE/Yocto builds with pinned inputs, so the bill of materials stays explicit and maintainable over time. Releases result in signed artifacts that can be traced from CI to factory to field:
This reduces unknown-state devices and turns security patch delivery into a repeatable process instead of a risky one-off event.
Tempo2Market supports automatable end-of-line (EOL) workflows that scale from pilot batches to series production. The goal is simple: every device leaves the factory in a state that is ready for lifecycle operations, not just "it boots".
Typical EOL steps include:
fleetwarden and assigning the device into the correct fleet/group.These validation gates reduce field failure rates, shorten commissioning time, and ensure that governed updates, configuration, telemetry, and LIVE support work reliably from day one.
Tempo2Market is designed to be adopted in a way that matches an OEM’s reality: some teams want an end-to-end platform that works out of the box, others want to keep parts of their existing stack and only replace the risky pieces. hexDEV therefore offers Tempo2Market as modular building blocks, complemented by engineering services, onboarding, and long-term maintenance support. The objective is always the same: reduce platform risk and time-to-market while keeping devices updateable and supportable over their full lifecycle.
A complete platform delivery for OEMs who want to ship a connected embedded product without assembling and integrating multiple vendors. Typical scope includes:
ttmdaemon),fleetwarden (OTA rollouts, configuration, telemetry/logs, LIVE support).This package is the fastest path from prototype to field-ready fleet operation with a consistent end-to-end chain of trust.
Tempo2Market can also be adopted in parts—for example when an OEM already has hardware, a cloud backend, or internal processes in place, but wants to remove specific pain points. Common modular entry points are:
fleetwarden for governed OTA, fleet operations, and LIVE support,ttmdaemon as on-device API anchor to stabilize applications across hardware/software changes,This reduces integration risk while allowing OEMs to keep what already works in their organization.
For web-panel and HMI deployments with a strong focus on hardware installation options, Tempo2Market is available as a packaged solution by TCI GmbH called SmartStart.
By utilizing Tempo2Market, TCI incorporates the hex-browser for kiosk and HMI applications, a configuration interface, and centralized lifecycle management through fleetwarden.
If desired, hexDEV can deliver a turnkey solution from “idea to series”: hardware variant work, platform integration, application development (web/Qt/QML/mobile as required), manufacturing onboarding, and rollout operations. This model is useful when an OEM wants a single accountable partner for implementation and lifecycle readiness.
Tempo2Market is backed by hands-on engineering services to ensure the platform fits real-world constraints: field wiring, production workflows, security requirements, and operational processes. Typical service domains include:
fleetwarden integration, custom cloud apps via APIs, dashboards, telemetry/log evaluation workflows.hex-browser, configuration UIs, Qt/QML components, integration with customer backends.Where appropriate, hexDEV works with partners (e.g. panel vendors, manufacturing partners, and domain specialists) so that Tempo2Market deployments remain scalable beyond individual pilot projects.
hexBLUE, equipped with hexNFC.A platform only scales if engineering teams can adopt it quickly and operate it safely. Tempo2Market therefore includes enablement deliverables such as:
The roadmap is focused on strengthening the platform defaults and accelerating adoption:
hexIO to production readiness to enable robust PLC-style cabinet deployments together with hexBLUE.hex-browser).Tempo2Market improves sustainability primarily by extending device lifetime and reducing duplicated engineering effort:
Selected customer references (non-exhaustive). Depending on project scope, customers use the full Tempo2Market stack or selected components (e.g., fleetwarden, provisioning, ttmdaemon, or the embedded platform layer). Details may be subject to confidentiality agreements.
hexLIN, a USB LIN-BUS adapter for Linux. It allows Linux systems to communicate with a LIN bus. It can be used in both master and slave mode, and is primarily intended for use in research and development. See more at: https://hexdev.de/hexlinfleetwarden-based expertise for connected embedded solutions and lifecycle operations.hexBLUE embedded system together with the hexNFC adapter, as an access control system. The solution is deployed in a custom enclosure, communicates with a backend service, and performs user authentication via NFC for controlled entry scenarios.Tempo2Market combines open-source components with proprietary core IP.
ttmdaemon (on-device runtime / application server and API anchor), fleetwarden (lifecycle cloud and fleet operations)Tempo2Market is designed to make patchability and lifecycle accountability practical: secure boot, signed update chain, device identity, and governed rollout processes are treated as baseline platform capabilities. This supports an engineering posture aligned with modern IoT cybersecurity expectations and emerging regulatory requirements.