Skip to content

Case studies

Systems we have built

These production systems connect vehicles, edge devices and cloud platforms, and support engineering and customer service teams. Each case describes the problem and our solution.

Filter by field

Showing 11 of 11 case studies

01Cloud platforms

Shared cloud platforms with GitOps and monitoring

  • Kubernetes
  • GitOps
  • Terraform
  • Observability

AProblem

Multiple teams needed to share cloud infrastructure while working independently. Changes had to be traceable, and each team required visibility into the behavior of its own workloads.

BSolution

We design and operate shared Kubernetes platforms based on GitOps. Configuration is declarative and versioned, and multi-tenancy allows teams to work independently on shared infrastructure.

Reusable Terraform modules provision cloud infrastructure, clusters and tenants. CI pipelines validate and plan each change before promoting it through development, staging and production.

The observability stack combines Grafana Mimir for metrics, Tempo for traces, Loki for logs and Pyroscope for continuous profiling. Each team can inspect the behavior of its workloads.

devstagingprodteam-ateam-bmimirtempolokipyroscopeinfraclustertenantrepositoryterraform plan+ 2 to add~ 1 to change- 0 to destroyvalidateplan01Git and CI02EnvironmentsGit, versioneddesired statemerge request,terraform planTerraformmodulesvalidate andplan in CIGitOps pullsand reconcilesTerraformprovisionspromoted dev,staging, prodtenants asnamespacesGrafana Mimir,Tempo, Loki,Pyroscopeper-teamobservability
Plate 01Cloud platforms

02Edge platforms

Kubernetes inside development vehicles

  • Kubernetes
  • Edge computing
  • Automotive

AProblem

Software updates for development vehicles had to be scheduled dynamically and for each vehicle individually, without manual operations.

BSolution

We built the platform on Kubernetes, which the teams already used in the cloud. Engineers continued to work with tools they knew, and the vehicles became part of the same toolchain.

Kubernetes is designed to distribute workloads across a cluster of servers. A vehicle's lifecycle, with startup, sleep and retirement, differs from that of a cloud server. We connected the existing tools with our own scheduling and installation logic, which targets individual vehicles and follows their lifecycle.

Updates reach each vehicle automatically, and the platform controls the application lifecycle more precisely than standard Kubernetes.

kubernetes nodeapp aapp bdata flowspowerdeployments01Control plane02Edge device03Development fleetkubernetesSDK fordev teamssubscriptionsqueued untilwake-upscheduledworkloadswaits formemorypowerlifecycledatadeploymentsrunningasleep
Plate 02Kubernetes at the edge

03Edge to cloud

A digital twin that supports older clients

  • GraphQL
  • Distributed systems
  • Data

AProblem

Integrations required live vehicle state in the cloud and, in some cases, on the vehicle itself. The platform had to evolve without breaking integrations built against earlier versions.

BSolution

We developed a digital twin database that synchronizes vehicle state bidirectionally between cloud and edge. Clients access it through a stable GraphQL schema while the twin ingests a continuous stream of fleet state changes.

Internal schema migrations maintain compatibility with older clients, so existing integrations continue to work as the platform evolves.

graphqlv1v201Cloud02Vehiclefleet statechangestwindatabasedigital twinof the vehicleGraphQL withschema migrationsolder andnewer clientstwo-waysynctwin replicaon the vehicle
Plate 03Digital twin

04Edge to cloud

Remote vehicle commands with live status

  • Real-time
  • Security
  • Edge computing

AProblem

Applications needed to trigger functions, measurements and routines on vehicles remotely. Vehicle software changed frequently during development, which changed the set of available commands, and callers needed to know whether a device could execute a command.

BSolution

We built an authenticated command system with live delivery. Continuous health checks report whether a device is able to execute a command.

Running containers register their available actions dynamically, which keeps the command catalog aligned with the software on each vehicle.

newappappappcommandsready01Command service02Vehicleactioncatalogapplicationauthenticationlive devicestatusregisters itsactionsauthenticatedcommandhealthchecksrunningcontainers
Plate 04Remote commands

05Fleet operations

Vehicle software updates with automatic recovery

  • OTA
  • Reliability
  • Fleet management

AProblem

Each vehicle required a specific set of software and measurement configurations. Updates had to withstand power loss during installation.

BSolution

We developed an over-the-air update stack that selects target vehicles through filters on their digital twins. Teams can configure each software component per vehicle.

A staged pipeline handles delivery, installation and monitoring. After an interrupted installation, the stack detects corrupted software and restores it automatically.

deliverinstallobserve01Rollout02Vehicledigitaltwinsfilter selectsvehiclessoftware setper vehiclestagedpipelineinstallmonitoringautomaticrecoverycorruptiondetectedpower lossmid-install
Plate 05OTA updates

06Automotive

Remote vehicle flashing and diagnostics

  • Diagnostics
  • Workflows
  • AI

AProblem

Flashing electronic control units and performing diagnostic maintenance typically required a specialist on site at the vehicle.

BSolution

We integrated an existing flashing and diagnostics stack into our edge cloud platform, which allows these procedures to run remotely.

Specialists define procedures in a workflow system and distribute them across vehicles and technicians. AI agents support the drafting and editing of these workflows.

diagflash01020304agent01Workflow system02Vehicles and techniciansAI agents helpdraft and editspecialistdefines theprocedureworkflow stepsdistributedto vehiclesdistributedto techniciansdiagnosticresultsflash anddiagnosticsstackECU beingflashedno specialiston site
Plate 06Remote flashing and diagnostics

07Automotive

SOME/IP in Rust with runtime configuration

  • Rust
  • SOME/IP
  • Protocols

AProblem

Conventional SOME/IP stacks fix the communication matrix at compile time, so every change to the vehicle configuration requires a rebuild and redeployment. The stack also had to deliver high-throughput data to parallel consumers on constrained hardware.

BSolution

We developed a SOME/IP stack in Rust that loads its ARXML configuration at runtime. New vehicle configurations take effect without recompilation or redeployment.

Rust provides memory safety without a garbage collector. A concurrent architecture delivers high-frequency data to multiple consumers on the same constrained hardware.

configsome/ip stackrust<arxml> v1<arxml> v2n020101Consumers02Constrained hardware03Vehicle networkparallelconsumershigh-frequencydataRust SOME/IPstacklimitedmemorynew ARXMLconfigurationloaded at runtime,no rebuildSOME/IPAutomotiveEthernetECUs
Plate 07SOME/IP in Rust

08AI in operations

AI agents for support triage and response drafting

  • AI agents
  • Support
  • Automation

AProblem

The volume of incoming support tickets exceeded the capacity for manual triage.

BSolution

We built a support system in which AI agents classify incoming tickets, analyze issues and draft responses. Integrations give the agents access to live platform data and functions, so each draft reflects the current state of the system.

Support engineers can focus on the cases that require their judgment.

serviceserviceserviceai agents01Support02Platformincomingticketscomplex casesto an engineerAI agentsclassifyanalyzeand draftdraftresponselive platformdataplatformfunctionslive platformsystems
Plate 08AI agents in support

09AI in engineering

Isolated environments for coding agents

  • AI agents
  • Developer experience
  • Security

AProblem

Coding agents require controlled environments. Without isolation they can access developer machines and shared infrastructure, and they have no knowledge of the team's engineering practices.

BSolution

We built a configurable sandbox that isolates agent execution from the host. The same setup runs locally or remotely and supports different tools and workflows.

Agent skills document our engineering practices and guide the agents through the team's development process.

server$agenttoolsfiles$agenttools<skill><skill><skill>01Agent skills02Sandboxesagent skillsthe team'sengineeringpracticesguides the agentsthrough the team'sdevelopment processcoding agentlocalsame setup inboth placesno access tosharedinfrastructureremoteisolated fromthe host
Plate 09Agent sandbox

10Open source

Kelon: centralized authorization policies

  • Authorization
  • Architecture

AProblem

Authorization rules for roles, hierarchies, tenants and exceptions are often spread across application code, which makes them difficult to maintain, audit and test.

BSolution

We developed Kelon, an open-source permission system that separates authorization rules from application logic. Services query declarative policies that teams maintain in one central place.

Kelon runs in production and serves as a reusable authorization component in customer applications.

View the source on GitHub
orgteam abillingteam bprojectsreportssearchpackage projectsallow ifuser.team == teamkelonadminteam-a devteam-b dev01Users02Kelon03Web servicesusers sendrequestsKelon guardsevery requestgate opens:allowedpolicies inone placegate closed:team-b devdeniedorganizationprotectedperimeterservicesaccessinherited downthe hierarchy
Plate 10Kelon

11Open source

Doras: delta downloads for container registries

  • OCI
  • Edge computing

AProblem

Edge devices often operate on slow, metered or unreliable connections. Downloading a complete container artifact for a small change consumes unnecessary bandwidth.

BSolution

We developed Doras, an open-source system that transfers only the difference between an OCI artifact in the registry and the version already on the device. This reduces the data transferred for each update.

View the source on GitHub
edge devicev2dorasv1v2doras serverpatch.bsdiff01OCI registry02Edge devicelarge updatebundleDoras buildsthe deltadelta, onlywhat changedstored in theOCI registryfull bundlenot downloadedonly the deltatravelsslow, meteredlinkapplied to thecurrent versionopen sourceclient
Plate 11Doras

Contact

Planning a platform, a fleet backend or a migration?

Tell us about it and we will get back to you.

Start a conversation
Location
Munich, Germany