From Architecture Ideas to Running Code — An OTA Prototype in Go

Recently, I spent some private learning time building a generic OTA proof of concept from scratch.

Over the last decade, I have worked with different architectural concepts for OTA systems. In this private learning exercise, I wanted to explore the capabilities of AI-assisted coding and chose a representative OTA use case to implement in Go.

The goal was not product development.

The goal was to turn architecture ideas into running code, practice AI-assisted development, and validate a few design decisions in a hands-on way.

1. Infographic

OTA Infographic
OTA Architecture Part 1
OTA Architecture Part 2

2. What I Built

The prototype covers a complete OTA workflow end to end:

  • Submit

  • Download

  • Transfer

  • Apply

The implementation is built as a set of Go-based services communicating through MQTT, with REST interfaces where needed and a lightweight admin portal to visualize progress.

At a concept level, the flow is simple:

  • Submit — Register an update package and its metadata.

  • Download — Fetch the artifact, verify integrity, and support resumable progress.

  • Transfer — Flash the artifact to a target ECU or simulator through a diagnostics-oriented transfer flow.

  • Apply — Execute an A/B partition swap concept, probationary boot, and commit.

3. A Few Architectural Choices I Wanted to Test

Event-driven coordination over MQTT. Instead of direct service-to-service RPC, the OTA Update Manager publishes commands and workers respond asynchronously.

State-machine-based orchestration. The OTA Update Manager drives the full lifecycle through explicit states and sub-states.

File-based persistence. No database was used. The prototype persists runtime state in JSON files so it can survive restarts and resume work.

Integrity check before apply. Verify the transferred image before touching boot partition logic.

A/B update strategy. Model safer update behavior with rollback capability when the new image does not boot as expected.

Minimal frontend. A lightweight portal was enough to visualize progress, phase transitions, and end-to-end workflow status.

4. What I Found Interesting

This exercise was valuable because it connected several areas that are often discussed separately:

  • OTA workflow decomposition

  • Event-driven software design

  • State machine modeling

  • Artifact download and resumable progress handling

  • Transfer and integrity verification concepts

  • A/B update and rollback behavior

  • Practical Go service decomposition

  • AI-assisted coding as a real engineering accelerator

What stood out to me most was this:

Architecture discussions become much sharper once the ideas are forced into running code.

Some design decisions become stronger. Some assumptions break quickly. Both outcomes are useful.

5. Why I Did This

This was also an intentional exercise to explore AI-assisted coding in a practical engineering context. I wanted to see how far AI could help in turning a system concept into a working prototype, while still keeping architectural control, reviewing design choices critically, and learning through implementation.

6. Important Disclaimer

This was developed privately as a generic learning and prototype exercise.

It is not connected to my current employer, any previous employer, or any customer or OEM project.

It does not represent any production system, confidential implementation, or project-specific architecture.

The purpose was purely personal learning: to exercise OTA concepts in Go, explore AI-assisted coding, and validate generic architectural ideas through a proof of concept.

Built with Go, MQTT, AI assistance, and curiosity.

#OTA #EmbeddedSystems #AutomotiveSoftware #GoLang #SoftwareArchitecture #Microservices #Diagnostics #DoIP #UDS #AI #AICoding #Prototype #LearningJourney