Embedded World 2026 Recap: AI, Safety, and the Tools That Stood Out

I’ve been going to Embedded World long enough that I can usually predict the themes before I arrive in Nuremberg. AI. Safety. Connectivity. Repeat. Embedded World 2026 felt different.

Not because the topics changed but because the conversations did. Less “here’s what’s coming” and more “we’re out of time.” CRA deadlines are real. AI tools are actually shipping. And a few things on the show floor genuinely stopped me cold.

In this post, I’ll share my Embedded World 2026 recap, from AI agents running LDRA through MCP servers, to the CRA anxiety that was everywhere, to SEGGER’s award-winning emApps, and the hardware tool that stopped me in my tracks. I’ll also walk through the Zephyr RTOS demo I built for the show that I think is super cool and will give you some ideas on how to modernize your firmware.

Embedded World 2026 Highlight: AI Agents in the Firmware Toolchain

A year ago, AI for embedded was mostly demos and hype. In fact, not many people were even talking about using AI for embedded. The consensus among the folks I talk with is that embedded systems are special and that AI has no place in the industry.

And yet, at Embedded World 2026, I saw numerous product offerings that were pushing AI into the industry. However, these weren’t hyped demos but actual products with paying customers. That’s a meaningful shift.

The conversations I found most interesting weren’t about which model writes the cleanest C. They were about AI agents and MCP servers. Specifically, wiring AI into the development workflow so it can call tools in the background without the developer having to context-switch out of their editor.

Agents Running LDRA through an MCP Server

For example, I saw a demo at the Tasking booth that used an AI Agent to connect to LDRA tools through an MCP server to analyze and fix code. Instead of manually kicking off an analysis cycle, or manually generating test cases, an AI agent invoked an MCP (Model Context Protocol) server, interpreted the results, and even made corrections based on what it found. The compliance artifact was still generated. The developer never left their workflow. Quality was built into the workflow. That’s the actual value proposition.

Below is my poor attempt to capture what was happening:

I did manage to find a video from the conference here, that gets the general point across, but the live demo was far more impressive. Especially when you just have two engineers talking tech and geeking out.

AI-Powered Unit Testing

I know we embedded developers aren’t big fans of unit testing. I’ve found unit testing to be the one skill that revolutionized how I built systems, taking me from spending all my time debugging to spending my time building new features.

The one area that AI seems most primed to help embedded teams is in developing unit tests. There were several booths that highlighted AI-Powered Unit Testing. Many of these were targeting the automotive industry, but I think their technologies and ideas can certainly be applied to nearly any embedded industry.

As I spoke with various companies about their unit-test solutions, I found that a common pattern emerged. AI generates the test scaffolding, the engineer reviews and tightens it, and an MCP server orchestrates the rest. The developer stays in the loop and in control. Meanwhile, the workflow ensures coverage measurements, static analysis, and that results are logged.

For teams building high-reliability firmware, removing that friction matters. The steps don’t get skipped because they’re annoying to set up. Or because you don’t know how to write tests. AI can help guide that process with the engineer redirecting AI when it gets off target.

I will warn you though, I think it’s easy to drink the Kool-Aid of the AI revolution. I believe these tools can be used to develop higher-quality firmware faster, but ultimately it’s human engineers and the humans that run them that will be responsible if something goes wrong. Leverage this technology, but tread carefully, please.

Note: A year ago I would have pushed back hard on this in a safety-critical context. After the conversations I had this week, I’m watching this space very closely. Some of the implementations are genuinely thoughtful, but also a bit scary when you think about the repercussions.

CRA Was Everywhere at Embedded World 2026

If there was one theme impossible to ignore at Embedded World 2026, it was the EU Cyber Resilience Act. Nobody was relaxed about it. Not the vendors. Not the product teams. Nobody.

CRA was a main stage topic, a booth conversation, and based on the expression on a lot of faces, a source of genuine anxiety. The enforcement timeline isn’t theoretical anymore, and companies are starting to reckon with what it actually takes to build and maintain the audit trails, SBOM generation, and vulnerability disclosure processes the regulation demands.

Fortunately, the tooling ecosystem is responding. There were several vendors showing solutions aimed directly at the CRA compliance workflow. None of it is trivial. But the options are improving.

If you’re leading a team building any connected product that touches the EU market, this isn’t something you can hand off to a compliance department. It touches your architecture, your update mechanism, your dependency management, and your documentation practices. The sooner you treat it as an engineering problem, not a paperwork problem, the better off you’ll be.

emApps from SEGGER Took Home Best in Show Award

Segger’s emApps won at the show, and once you understand what it actually does, the award makes sense.

The concept sounds almost too ambitious for embedded: bring the familiar flexibility of the smartphone to the world of embedded systems. Instead of fixed firmware, emApps adds an application layer where small programs (apps) can be dynamically loaded and executed in a sandboxed environment, isolated from the core firmware and from each other. Add new functionality to a shipped product without touching the validated firmware underneath. For safety-critical teams, that’s not a minor capability.

But the implementation is what makes it credible. The executor, the tiny runtime engine embedded in firmware, runs at around 1 KB. Apps start at under 100 bytes, so you’re not blowing your memory budget to get dynamic loading. Any attempt to access memory outside an app’s sandbox is intercepted immediately, returning control to the firmware. System stability stays intact.

There’s another angle worth considering for safety-critical teams. Non-essential features like GUI control, display logic, and communication overlays can be isolated as apps and excluded from your certification scope entirely. If you’ve ever been through a DO-178C or ISO 26262 effort, you know exactly how valuable it is to draw a hard line around what needs to be certified and what doesn’t. emApps gives you an architectural mechanism to do that cleanly, rather than trying to argue boundaries after the fact.

This isn’t a theoretical product either. Segger has been using emApps in their J-Link and Flasher product lines for years. That matters. After all, tool companies that actually run their own products on their own frameworks tend to build things that hold up.

PCBite Was the Hardware That Stopped Me

I want to be honest about this one. I walked past the PCBite booth, circled back, and stayed longer than I planned.

The concept is simple. Magnetic, hands-free probe holders. Set up your debug configuration on a board, park the probes where they need to be, and they stay there! No tape, no jigs, no third hand required. For anyone who has tried to probe a fine-pitch connector while simultaneously operating a scope, the appeal is immediate.

I want one. I brought the pamphlet home and plan on buying a set for my own workbench. A colleague mentioned they’ve been around for a while and are expensive. Honestly, for what it does, I believe it’s well worth it. This doesn’t make headlines in architecture discussions. But it shows up in how fast your team iterates on hardware bring-up, and that time adds up.

Worst case, I know what I want for my birthday and/or Christmas!

Beningo Embedded Group Demonstrating Zephyr RTOS and Modern Development Processes

All the years I’ve gone to Embedded World, I’ve never had a booth. I’m an engineer, and not a sales and marketing person. It’s my least favorite part of being a solo consultant. I’d rather just geek out and help teams succeed and learn. But a mentor once told me that if I don’t tell folks about all the great things I’m doing, no one will!

So, for the first time, I had a little kiosk within the Zephyr booth. Mohammed Billoo and I have been partnering on Zephyr Training and Consulting, so we took turns manning the booth and getting around the conference to see what was interesting.

Out of everything, and in a biased way, I think what we were showing was pretty cool. I wanted to show how powerful Zephyr can be and how you can take a modern approach to designing and building Embedded Systems.

But what do you demo when you only have two days to prepare for the show? Something exciting, yet throwaway after the expo. You want to show something cool, maybe even something with some fire to it to catch attention. With my history in space systems, I decided that a from-scratch mock-up of a propulsion system would be interesting!

I could simulate it with an open-source emulator like QEMU, transfer it to hardware, and use a web-based application to demonstrate simulation->hardware, then hardware-in-loop control and testing. My interface looked like the following:

Simulation is awesome, but let’s be honest, I’m an embedded systems engineer, and it’s just not the same without hardware. (I know there is no hardware, only data, but eventually, once you have something mocked up, you want to test it on hardware!).

So, I put together a little mock-up. It had no real tie to any real flight hardware or software, just a demonstration of what can be done with simulation and some hardware skills in a few days. I don’t think the result was too bad:

I used LEDs to simulate thrusters and a BLDC motor drive to simulate a fuel pump. I could examine the software’s behavior using the serial console. Proto Buf messages were sent over serial to command the system and receive back some basic telemetry. Most importantly, the GUI did have fire when the pump was on and the thrusters were enabled! That helped catch the attention of folks walking by.

It was a super fun experience. Overall, I talked to more than 200 developers and managers about Zephyr and Modern Development Practices. I even ran a half-day seminar on Faster. Smarter. Firmware.

What My Embedded World 2026 Recap Comes Down To

The industry is being pushed by regulation, by automotive transformation, by AI tooling that’s actually maturing toward more disciplined, more documented, more testable firmware development.

That’s the right direction. It’s also uncomfortable for teams that have run on informal practices for years. The tools are there. The standards pressure is real. What’s usually missing is the organizational will to treat firmware with the same engineering rigor applied to other disciplines.

The Embedded World 2026 show floor changes every year. That underlying challenge doesn’t. Sooner or later, if you don’t adopt modern practices, you’ll get bitten by regulations or accrue so much technical debt that your development efforts will come to a standstill.

That doesn’t have to be you, though. Stay up to date by signing up for my Embedded Bytes newsletter, and most importantly, keep learning and applying better practices to the way you design and build embedded systems. If you ever need help, you know where to find me.