Abstract

Ground, TX, RX. Three UART pins, a two-dollar serial adapter, and a live U-Boot prompt — and the secure boot chain you spent months designing stops being a chain.

This talk walks through what actually happens at that prompt on a shipped device: rewriting bootargs to land a root shell, sideloading an unsigned kernel, dumping flash, pulling secrets out of RAM. None of it is novel. All of it still works on hardware being manufactured today.

Then the uncomfortable part: the mitigations most teams believe in don't hold up. bootdelay=0 is not a defense. A depopulated header is not a defense. CONFIG_AUTOBOOT_KEYED has footguns. Signing the kernel means little when the environment deciding which kernel to boot sits outside the chain of trust. We'll go through the short list of things that genuinely lock U-Boot down for production, and the longer list of reasons teams skip them anyway.

If you ship connected hardware and you've never attacked one of your own devices with a serial cable, you should. Someone else already has.

Abstract

Test automation in embedded systems is often limited by physical hardware access. Teams build custom setups that work locally but do not scale, leading to fragmented workflows and duplicated effort.

We present a unified approach based on Labgrid, developed for a large-scale board farm at Analog Devices. The system connects hundreds of devices across locations and exposes them through a single interface. Hardware remains local but becomes globally accessible, allowing engineers and automated agents to interact with real targets as if they were on their desk. The key idea is to treat hardware as a shared, schedulable resource, enabling collaborative development, reproducible testing, and CI/CD integration.

Built on and contributing to the open-source Labgrid ecosystem, our approach emphasizes extensibility and collaborative development. We also explore how AI-driven agents can directly access and operate real hardware to debug issues and assist development. We share practical lessons and demonstrate how testing can evolve from isolated setups to scalable, and open infrastructure.

Abstract

Hardware-in-the-Loop (HIL) simulation is a proven method for validating embedded electronics in demanding environments — from high-power systems and battery management to robotics and industrial controls. Traditional HIL setups depend on FPGA-based platforms and proprietary toolchains. The associated licensing costs, specialized expertise requirements, and long integration cycles create significant barriers to broader adoption.

This session presents an alternative architecture that achieves real-time embedded testing fidelity using standard microcontrollers, open source firmware, and AI-assisted toolchain generation. Rather than replacing simulation rigor, the approach redefines where complexity lives: AI code generation handles the labor-intensive creation of plant models, hardware abstraction layers, and communication interfaces, while standard microcontroller hardware provides the real-time execution substrate. A live motor control demonstration will showcase the complete workflow — from plant model simulation to real-time embedded testing — illustrating how this approach delivers results comparable to traditional HIL systems at a fraction of the cost and complexity.

Abstract

Functional safety has traditionally been the domain of electronic hardware engineers. However, as safety-critical systems rely more and more on software, a new challenge emerges: how do we ensure functional safety when the boundary between hardware and software becomes blurred?

This talk presents a practical approach using co-simulation of microcontrollers and analog electrical circuitry to bridge this gap. The presentation covers:

• setting up a co-simulation linking microcontroller code with SPICE-based analog circuit models and
• performing automated Failure Modes, Effects, and Diagnostic Analysis (FMEDA) across the hardware-software boundary

Attendees will leave with actionable insights on implementing co-simulation in their development process, enabling functional safety engineers to address safety concerns holistically rather than treating hardware and software as separate silos. This approach reduces late-stage safety validation failures and accelerates certification processes.