How to Test Embedded Software Before the Hardware Exists
For embedded and firmware teams, systems engineers and scrum masters in defense and aerospace, and anyone whose software schedule waits on hardware.
About Peter Brady
Peter Brady is the founder and CEO of Certo Systems, an Arlington, Virginia company building Certo EMU, a real-time emulator of custom hardware that lets software teams build and test against a device before the physical hardware exists. He is known for treating the hardware bottleneck in embedded development as a communication problem between hardware teams, software teams and management, and for making hardware behaviour a versioned artifact that each team can work against locally. A software engineer with a bachelor's in electrical engineering and a master's in computer science from Syracuse University, he built his career in signals intelligence and digital signal processing for RF applications, including at CACI International and BlackHorse Solutions.
Peter Brady founded Certo Systems out of a problem he lost years to himself. Every team he worked on wrote software that had to talk to expensive custom hardware, nobody had enough of the hardware, and the simulators they built to cope with that did not behave like the real device. "I have been bottlenecked and everyone on my team has been bottlenecked from having the real thing." His diagnosis is the interesting part, because it is not an engineering one: "it's more of a communication problem between management, hardware teams, and software teams," three groups working at speeds that cannot be reconciled, with the cost landing as schedule. So the product is an agreement rather than a simulator, a scripted artifact of how the hardware behaves that comes out of the hardware design and is "versioned as if it was software." He gives up ground before he claims any, naming the digital twin companies and saying "I absolutely cannot compete with" them, then keeps the narrow thing that matters to a defence customer: it runs on the engineer's own laptop, needs no code changes, and the data never leaves. He is in beta with no first customer, says so on the record, and when asked what he needs most he asks to be told whether the idea is worth paying for. That is the throughline 79 Development keeps coming back to. The expensive failure is rarely the technical work, it is the gap between what one group knows and what the next group can act on, and closing that gap is what makes a company legible to buyers and to the systems now answering on their behalf.
KEY TAKEAWAYS
- The bottleneck was never the hardware, it was waiting for the hardware. He starts from his own career rather than a market thesis. "Most of the software, pretty much all of it throughout my career, has had to interface with that hardware. And I have been, to create my software, I have been bottlenecked and everyone on my team has been bottlenecked from having the real thing, because a lot of times it's a very expensive piece of hardware." The workaround is universal and it is the problem: "we end up having to create our own simulators and all sorts of stuff. And so what that does is it will not exactly match the behavior that's expected from the real system."
- He diagnoses it as a communication failure, not an engineering one. The most useful reframe in the conversation, and it is what separates his product from a better simulator. "It's more of a communication problem between management, hardware teams, and software teams. Trying to coordinate the exact behavior between all of them when we work at different cycles, because software can move a lot faster. Hardware is a little bit harder to move so fast." Everything he builds follows from that: the artifact exists so three groups can disagree in one place instead of three.
- Make hardware behaviour a versioned artifact and the argument ends. His actual proposal, in his own terms. "I'm trying to make somewhat of an artifact that comes from the hardware designs that can be used to execute against the software, so it be scripted to work just as intended and designed, and versioned as if it was software. So every time hardware team goes, oh, that's not really going to work for us, they can create a new version of their artifact, and then the software team can get that and work against it." He calls it a virtual hardware behavior artifact, and is careful that Certo supplies the mechanism rather than the contents: "I'm not really meant to know all that stuff," because the behaviour being modelled is usually proprietary.
- He named the competitor he cannot beat, and then said where he still fits. Asked to place himself, he gives up ground first, which is rarer than it should be. "Early on I was trying to figure out who my competitors were, and there's a whole host of digital twin creators for pieces of even hardware and physics and all this sort of stuff, which I absolutely cannot compete with. And that's not really our point." The distinction he keeps is practical rather than grand: a digital twin is an upfront project needing everything at once, contractors, and a cloud service you change your codebase to call. His runs on the engineer's own machine, with no code changes, using the same interfaces a debugger already uses. For teams whose whole problem is that the data cannot leave the building, that is the difference that decides it.
- Compose the artifacts and you get an aircraft, plus the bug you could never reproduce. Where he thinks it goes, worked through out loud. Each team on a large integration ships its own artifact, "so you have the HVAC team or the hydraulic team, the electrical control team, and they all provide their artifacts," and those compose into a higher-fidelity simulation of the whole machine. The payoff he cares about is the replay: "during this particular simulation of turbulence, the electrical system failed, and these were the messages that came from it," recorded, handed back to one engineer, replayed locally. "It's not real-world scenarios, so you don't get the real-world bugs," and being able to reproduce one on a laptop is the thing the current process cannot do.
- Asked what he needs, he asked for a verdict rather than a cheque. The show's standing closing question, and the answer is unusually unguarded for a founder on a microphone. "Our one thing is really getting eyes on it and people using it. I'm very interested in feedback and I'm still searching for that first customer and first user, so it's something I really believe in. However, I understand businesses don't always work out, but I think it's an important thing. And really just looking for people to say like, yes, this is it, or these are some tweaks, or this isn't worth my money kind of thing." He also names the go-to-market problem honestly: his buyers are defence contractors, "everyone's very secretive," and he has not yet found the door.
FULL TRANSCRIPT
What We Need to Grow, Episode 045: Bottlenecked From the Real Thing. A Founder Talk conversation with Peter Brady, Founder and CEO of Certo Systems. Cleaned for readability; the words are the speakers' own.
Caleb Pedosiuk: Hey Peter, great to connect today. So your company, Certo Systems, we're going to hear a little bit about what you're building with that on the hardware side of things. I haven't done a ton with hardware. Back in 2015 there was a startup I was working with that was doing some stuff with AI hardware, essentially aiming to be the interoperability between sensors. So gyroscopes and all that jazz, and trying to take all of that, decode it, and essentially alphabetize it so you could understand what's going on, different motions, and interface between some pretty big companies. Which was really cool, but I was very much over my head. So I'm excited to hear what you're building, but I feel like you might have to dumb it down a little bit for me from a hardware standpoint. You have, I think it's a master's in computer science and a bachelor's in electrical engineering. So please tell us a little bit about what's going on with this company, and where are you headed?
Peter Brady: Yeah, absolutely. First of all, thanks for having me. Super cool.
Honestly, like you, while I have the electrical engineering degree, I don't have as much professional experience making and creating firmware and embedded devices. However, most of the software, pretty much all of it throughout my career, has had to interface with that hardware. And I have been, to create my software, I have been bottlenecked and everyone on my team has been bottlenecked from having the real thing, because a lot of times it's a very expensive piece of hardware. And we end up having to create our own simulators and all sorts of stuff. And so what that does is it will not exactly match the behavior that's expected from the real system. And so a lot of times we'll have our own ideas of how we think it should go.
And it's more of a communication problem between management, hardware teams, and software teams. Trying to coordinate the exact behavior between all of them when we work at different cycles, because software can move a lot faster. Hardware is a little bit harder to move so fast. So the problem that I constantly came across was that there's that different cycle time, and being able to match up everyone's expectation between what's the expected behavior.
So with that problem laid out, I'm trying to make somewhat of an artifact that comes from the hardware designs that can be used to execute against the software, so it be scripted to work just as intended and designed, and versioned as if it was software. So every time hardware team goes, oh, that's not really going to work for us, they can create a new version of their artifact, and then the software team can get that and work against it. So that's in essence the whole story.
Caleb: So help me, or I'm not sure if I fully understand this. A really big aha moment for me maybe two years ago was, I think I had this natural misconception that these robots, let's say the Optimus robot or these humanoid robots, their adoption curve of their ability to work as efficiently as humans is going to be pretty steep. For example, you bring in a new employee to something like a restaurant to learn to bus tables, to serve stuff. Even a human being who's capable, understands English, has all their faculties working properly, they can speed up, slow down, there's going to be a certain amount of time it takes for them to be able to pick things up. It's going to take them some time. They might drop a tray, might bump into something coming around the corner.
Peter: I've done that so many times working in bus tables. Yeah, yeah.
Caleb: Yeah, exactly. And so there's a certain amount of it where you're like, oh, it's going to take them two weeks to even just be able to handle a shift without shadowing. And then you're probably six months before you're just humming. And I think my thinking was that it would be like that with a lot of robots. And I know from one robot to the next you can't clump them all together, but let's just say humanoid robots. And then it occurred to me, actually, the way they train can be through software. So they can simulate a hundred thousand different ways of coming in and out of the kitchen doors, with other staff coming through at different times, different times of day, different demand, and you can simulate that to be able to come up with the optimal cadence of things.
Now that doesn't mean it's going to be perfect out of the gate, but the learning curve can happen almost more like, maybe this is silly, but like in The Matrix where he's like, I know kung fu. Maybe that's extreme in that case. But the reason why I mention it is, as you were describing some of what you're doing, if I understand it correctly, it's like you want to find an effective way to take a company's piece of hardware and create a digital likeness of it that could then be used by other teams. You're essentially the digital functional harness of it to the real world, so that it can then figure it out. Almost like if someone's product was a Rubik's Cube, you would somehow find a way to create a digital version, an avatar of it, so that an Optimus could work with it in real time. Is that accurate?
Peter: Yeah, that's pretty accurate. In fact, early on I was trying to figure out who my competitors were, and there's a whole host of digital twin creators for pieces of even hardware and physics and all this sort of stuff, which I absolutely cannot compete with. And that's not really our point. But what you say is true. There's still a place, I think, for Certo, where we're meant for the engineers.
Let me back up and address the robot analogy, where I think a lot of that occurs once the full robot is complete. So those simulations of how to move in and out of the doorway, the robot has to be fabricated and put together, in my opinion, to be able to then exercise its learning. Where I'm hoping to go is, I've never worked on robots, but the team making the arm, and the software team, they can kind of break down the design and behavior of how the arm is supposed to move in different scenarios, and they can start working before all the components are fabricated or any custom components are needed, because you could take off the shelf what I'm describing as a virtual hardware behavior artifact. So that's the artifact. That's just the name that I have for it. And so you can run your simulation specific to that team, making sure if there's any malfunctions they need to take care of, whatever you can handle before everything's all done. So I'm mostly interested in exactly what you mentioned, but maybe pushing everybody a little bit to what they call shift-lefting, to try and get your testing done before you really are pressed for time.
And then each individual person on the team, I think where we stand out is every individual person on their team, on their local desktop or laptop or whatever, they can create their features and test against the virtual hardware behavior of the arm or leg or whatever it is, so that they know that their stuff is working against the design. Not against a simulator or something that may not be the exact behavior.
And why that's important is, when you make the actual digital twin, what I was alluding to before, you kind of need everything all at once. You need to have a digital twin creator create the physics and how things are. And it's like a whole other upfront cost, and there's contractors and stuff like that. Plus it's mostly, if not all, cloud-based. So if you have stuff that you want to protect, you have to change your codebase to use APIs to hit that cloud-based digital twin provider.
Whereas what I'm attempting to do is, everything is going to be local, there's not going to be any code changes, and it's going to use the same technology that's already existent in debuggers but used to help interface the hardware behavior artifact with your code. So if you're expecting your code to hit a `/dev` device, and forgive me if that's a pretty technical term, but for when the software is meant to interact with the actual hardware that's plugged into your computer, it will engage that interface, and that's where our hardware behavior will take over and start providing the real hardware behavior.
And I should also be clear, Certo is providing the mechanism for people to define their own hardware behavior, because of proprietary technology and stuff like that. I'm not really meant to know all that stuff. But it's a way for people to script their hardware behavior and have it interface as if it was the real hardware connected.
Caleb: So is your initial target audience in the defense space? Is it SIGINT and RF, with your background? Does that have you sort of honing in on one specific sector?
Peter: I think for the time being, yes. Mostly just stuff I can attest to, signal intercept and radio frequency technology. And yes, defense, because a lot of times they're the ones with the most expensive pieces of hardware and the largest teams that have to share, if they're even lucky enough to have a testing prototype to work with.
But yeah, so that's my intended target, but it has been difficult to branch into that, obviously. So I'm still figuring things out with who I can go to just for trying it out. We're still in beta right now, just to try and get initial feedback to even test my hypothesis.
Caleb: So hypothetically, you can wave a magic wand and have your ideal customer this afternoon. You've got ten people that have all said, hey, we're interested, Peter, we want to get some time on the calendar and chat. Who would you say these people are? Just as a profile, from a company, what industry, what are they working on, who is the person that really needs to see what you're doing, recognize the value of it, and then potentially say yes?
Peter: Yeah, I believe it would be, so to answer that question, there's been a very strong shift in the defense contracting field for agile methodologies. While it's a very good thing, it's trying to provide faster feedback for all teams, including hardware and software. And I bring that up because there's now agile coaches and scrum masters, and there's always been system engineers, but now they're trained on agile. And those I think are the target for me, the scrum masters and the system engineers.
Because the system engineers are focused on creating the interfaces between the hardware and the software teams. And so they're the ones that can most ideally create those artifacts that go, these are the data types, these are what the interfaces look like, and then here's the behavior of what the hardware should be and what the software should be. And so now you have everyone on your software team that can take that artifact that they create.
And the scrum master is the one that's trying to keep everyone making sure that they don't have any blockers. They're trying to figure out the scope of work, how everything kind of fits together. And I think they've felt a lot of the schedules fall through because hardware isn't ready yet, or the simulator provided information for the software team that now they have to go back and change something, and now they have to reiterate through another cycle. So I think those are the main ones in the defense contractors that I'm targeting, because they're the ones that are advocating most and talking most with the managers and the buying power, and they're talking with the engineers who are trying to get the work done but can't because they don't have the resources.
Caleb: Have you had conversations in aerospace? Teams that are looking more and more to increase the size of things that are going into space. I'm curious to know, if you're having to run simulations as someone who's lead on product and you're dealing with aerospace, if there might be a real niche there where they're looking to say, hey, this would be really helpful to have some of the capability that you bring.
Peter: Yeah, definitely. I'm very open, would be thankful for any links you could provide. I just haven't had the network for aerospace necessarily, but yeah, definitely one of the places we would be interested in.
Because one of the places we see ourselves going is, the defense contractors, or any other company that makes large pieces of hardware like Boeing, they'll make huge planes that integrate lots of different teams that are making their own part of the hardware. So one of the ideas I was thinking of is, each team essentially makes their own artifact, and then the idea is you can piece them together to then create the plane. So you have the HVAC team, or the hydraulic team, the electrical control team, and they all provide their artifacts. And now you have a higher fidelity simulation powered by the emulation of your hardware, to now be able to take raw sensor data into those systems to create a better quality test.
So now it's almost like an airplane simulator, but now you have more insight into what's happening at the hardware level. And what's happening at the interfaces. Where are the bytes going back and forth? And then you have a way to isolate that during this particular simulation of turbulence, the electrical system failed, and these were the messages that came from it. And now you can even record that, and then an individual engineer from that specific electrical control team could replay that on their own local computer, in their own local environment, to then replay the scenario that caused it, or dissect what happened.
So now you have a little more fidelity, but also the ability to replay the issue that happened, which is also an issue for these teams where it's not real-world scenarios, so you don't get the real-world bugs. And being able to replay them. So that's another aspect, being able to piece all the artifacts together to create an airplane and then a scenario with the airplane.
Caleb: And because so much of this information would be very sensitive depending on the company and what they're doing, you mentioned running something local. Is there a specific model? Are you using an open source model that you're running in some local version at the company level, so that they're not having a lot of this information potentially be ingested by some of the larger models?
Peter: Well, it depends on what you mean by model. So I apologize, I kind of jumped the gun there, but I don't necessarily have AI involved just yet. However, that is on the roadmap, and it's more to provide an MCP server around the data rather than creating my own model or anything like that. The idea being it'll be able for any kind of LLM, so they can choose whatever they want, to look at what the data is coming over, and what problems there may be.
Caleb: Okay. Well, the last question I'd like to leave guests with is to find out, what is the one thing that you need most right now to grow? For some it's like, hey, we're going into a series, we're trying to raise a Series A or a seed round. Some are saying, we're good on that front, we just need more exposure, awareness. Others are like, we need to really dial in product-market fit on this new thing we're working on. What would you say would be the one thing?
Peter: Yeah, I would say our one thing is really getting eyes on it and people using it. I'm very interested in feedback and I'm still searching for that first customer and first user, so it's something I really believe in. However, I understand businesses don't always work out, but I think it's an important thing. And really just looking for people to say like, yes, this is it, or these are some tweaks, or this isn't worth my money kind of thing. So that's what I'm really hoping to gain from the next thing to grow.
Caleb: Very cool. Well, Peter, I really appreciate getting to chat, and it sounds like you're working on something super niche and important in this area. Yeah, maybe outside of this we can chat a little bit. There's a couple people come to mind that maybe it may make sense to connect with. But thank you so much.
Peter: Yeah, thank you for having me.
What We Need to Grow is a conversation series by 79 Development, hosted by Caleb Pedosiuk. New episodes on YouTube and Spotify.