Systems, SDKs & Applied AI

Running automated tests on real household appliances is fundamentally different from testing pure software. If two processes try to switch a water valve or query a power supply at the same time, the test fails—or worse, the hardware gets damaged.

To solve this across 3 test benches and 9 test stands, I designed a decoupled, containerized microservices architecture where hardware access is strictly serialized, but test execution scales horizontally.

Why this architecture works so well:

• The Broker Pattern: Test containers never talk to the PLC or measurement devices directly. The Bench Broker container is the sole owner of physical I/O. It manages real-time asyncio WebSocket connections, ensuring safe state transitions.
• Dual Control (Auto & Manual): A dedicated WebApp container connects to the same broker, allowing engineers to either trigger automated CI runs or manually toggle relays, valves, and power supplies from their browser during debugging.
• Featherweight Footprint: Because the containers are stripped of bloat, the entire stack is remarkably lightweight. We don't need expensive server racks—an old office laptop easily powers a multi-stand bench (and if it weren't for proprietary x86 measurement device drivers, the whole host node could live on a Raspberry Pi).

Early on, writing a hardware test meant dealing with low-level communication quirks. Over several iterations, I designed a single, comprehensive Python SDK that serves as the standard development kit across multiple product lines.

• Non-Blocking Embedded Communication: Built on top of an asynchronous Python & DBus layer (alongside serial and pyLink bridges), the SDK talks to the embedded Linux boards inside the appliances without blocking test execution or UI monitoring.
• Zero Boilerplate for Engineers: The SDK handles fixture initialization, screen navigation, and background process monitoring under the hood. Engineers using the framework only write the high-level test intent.
• Self-Healing Test Runs: Hardware fails in unpredictable ways. One of the features I’m most proud of is the autonomous failure recovery loop. When a test fails mid-brew or mid-cycle, the framework captures the exact screen-by-screen trail leading to the error, intercepts the failure, orchestrates the PLC and software to bring the physical appliance back to its clean initial state (draining water, resetting power states, clearing errors), and continues executing the rest of the test queue 24/7.

Many legacy or entry-level appliance platforms cannot report their internal UI state over a bus—the only way to verify what the machine is doing is to look at its physical screen.

• Solving Data Scarcity with Synthetic Generators: Training deep learning models requires thousands of labeled samples across every language, icon state, and lighting condition. Rather than manually photographing and labeling coffee machines for months, I built a large-scale synthetic data generator that programmatically renders realistic images and video sequences of appliance displays—complete with glare, distortion, and dynamic transitions.
• Custom PyTorch Training Loops: Applying what I learned from a year of deep-diving into PyTorch, I wrote the custom training and validation loops from scratch, deploying production-grade classification and OCR models directly onto our test benches for real-time state detection.

When corporate tooling lags behind what engineers actually need on the ground, I build bridges to speed us up:

• Internal GPT & RAG Assistant: I architected a local developer platform combining a fine-tuned Mistral model with Retrieval-Augmented Generation (RAG) and vector search (ChromaDB/FAISS). It indexes our proprietary C++/Python codebases, Qt/QML UI components, and internal documentation so engineers can query system architecture and generate context-aware code safely inside the company network.
• 1-Month Cursor Prototype & A2A Workflows: When our teams struggled to get access to modern AI IDEs, I spent a month building a lightweight Cursor-like coding assistant prototype with Agent-to-Agent (A2A) workflows, giving our developers immediate AI acceleration while official tools were still stuck in approval pipelines.

I hate watching engineers copy-paste data between tools. I’ve tackled this problem from both ends of the software lifecycle:

1. Requirements-to-Code Parser: Human-written functional specifications are notoriously messy. I built an intelligent parsing engine that reads system requirement specs and automatically generates executable Python data structures and test stubs—establishing a true Single Source of Truth.
2. The Wiki–Jira–Polarion Release Pipeline: To automate test execution when new firmware drops, I built an integration service that watches Confluence software release tables, automatically spins up Jira tickets when a build is marked ready, generates the corresponding test runs in Polarion, and dispatches the jobs straight to our Dockerized test benches.