Case Study · Connected Devices

One HMI foundation. Multiple embedded products.

A modular runtime that decouples presentation, product logic and device services, proven through two intercom implementations with different feature sets.

Critical communicationsEmbedded LinuxC++ · Slint · GStreamer

HMI Runtime architecture

Experience and design tools

Product UISlint screens, themes and product-specific flows

Preview toolIndependent screen review with mock data

ConfigurationLanguage, installed content and product options

Stable contractUI adaptation and shared state

⇄

Reusable coreHMI Runtime modules and orchestration

Product and platform services

Call controlCalls, device state and service operations

Media pipelineGStreamer video and graphics composition

Device integrationKeys, display and target-specific events

Mockable interfaces keep teams moving

The challenge

A new family of embedded intercom products required more than a single application. Product variants would expose different modules, hardware controls and visual identities, while UI, backend services and device software needed to progress in parallel. A direct coupling between screens and services would make every new device expensive to develop and difficult to test.

Engineering approach

Crossware designed the HMI Runtime as a reusable layer between the product UI and the underlying services. Clear contracts separate presentation, shared state, business logic, media and hardware integration. Abstract backend interfaces allow real services to be replaced by mock implementations, enabling UI and feature teams to develop and verify their work before every target service is available.

ModularCapabilities can be included, replaced or extended by product variant.

UI-independentDesigners work against stable interfaces instead of backend internals.

TestableMock services reproduce calls, device events and backend behaviour.

DeployableDefined screen, configuration and service workflows support target delivery.

Two implementations

The architecture was validated by extending it.

The first implementation established the runtime, UI and media path. The second added call-control and device-input capabilities without redesigning the foundation.

Implementation 01

Video intercom station UI

The first product integration connected a Slint-based interface with video, configuration and device services on an embedded target.

Adapted an emerging Slint framework to product requirements
Created a standalone preview tool for UI designers
Rendered GStreamer video beneath the Slint UI using OpenGL composition
Introduced shared interfaces across multiple Slint files
Added gettext-based internationalisation
Defined the complete UI configuration and deployment workflow

Implementation 02

Call handling and device integration

A later product extension added concrete call and hard-key workflows while retaining dynamic Slint screen loading and the existing architecture.

Connected incoming-call acceptance to the call-control service
Added service-driven control of hang-up availability
Routed hardware key events from the device to the UI and back to services
Updated the runtime to Slint 1.17
Extended generated interfaces and mock-service behaviour
Validated feature integration without requiring every live service

Outcome

A product platform rather than a one-off HMI.

The runtime provides a repeatable foundation for embedded products with different screens, modules and hardware controls. New features can be introduced behind stable interfaces, teams can work in parallel, and target-specific integrations do not leak into every UI component.

Planning a reusable embedded HMI?

We can help define the architecture, interfaces, UI technology, media path and target integration.

Learn more →