Can modern software dev practices work with safety-critical embedded systems?

Philip Morgan

Expertise Incubator member Jeff Gable is working on an answer to that question. From his email list:

 • • • 

I work from home.

At the moment, I’m developing firmware for a surgical tool for a client. Next to my desk, I have a classic prototype setup for embedded device development. Boards screwed to a sheet of plywood, with motors and switches clamped down and wiring harnesses going everywhere.

Late last week, I was probing one of the connectors, and I accidentally shorted a pin at 24 volts to a pin connected to a digital input of one of the microcontrollers.

Boom. No more microcontroller.

Ok, it wasn’t dramatic. There wasn’t even a pop or smoke. But, the entire setup is now useless, at least until I get a new board, because I can’t test my code on the device.

If I worked in an office, the solution might be as simple as walking over to the supply cabinet and grabbing a replacement board (sheepishly explaining my mistake to my coworkers).

Since I’m working remotely, I’m out of luck, for at least a day, if not several days.

As it turned out, I indeed was not able to get a new board for several days. Sure, I could (and would) write code in the meantime, but if I can’t test it as I’m developing it, it’s likely that it will be a painful afternoon of integration and bug-hunting when I finally try to test several days of coding all at once.

Test-Driven Development to the Rescue!

I practice Test-Driven Development (TDD), which means that I write comprehensive unit tests as I’m writing the code. When I finish coding a software module, I have a high degree of confidence that it works, even before testing it on the device.

TDD has several advantages, which I’ll talk about at length. But, for our purposes today, TDD has a very compelling advantage:

I can make significant progress without testing on any hardware at all.

Blowing up a development board didn’t stop me. I lost barely any time.

Are your developers working from home, without access to hardware?

Don’t have enough prototype boards to go around?

Test-driven development can help.

Of course, it’s not as easy as flipping a switch. If you’re going to implement TDD at your organization, there are a few technical hurdles to overcome. More importantly, there are significant cultural hurdles to overcome. TDD requires a new mindset and a new way of working. It’s an investment, one that can be particularly difficult to make in the current uncertain environment.

I strongly believe it is worth it. I personally made a significant investment in time and money to be trained on how to do test-driven development correctly. I can tell you from the other side that the investment has paid off handsomely.


 • • • 

Jeff is working to advance the state of the art of software development for medical device embedded systems. Even if medical devices isn't your thing, you'll learn a lot about architecting and developing embedded systems via his several times per week newsletter:


There are 2 spots left in the TEI cohort beginning next month, in April. Information on the new program structure and new pricing here:

If you're interested in a closer look at how the program creates change, this unsolicited 14m video from Tom Miller is worth a look: