I find it incredible that they know where the problem is, but not how to fix it. Get 100-1000 of them and start stress testing them in a lab. This stuff isn't rocket science.
They should just print out a sign that says "lab" put it on an empty room, place the starter motor in the middle of it, and then suddenly they would know why it was broken. It is in a lab after all! This isn't rocket science! Or if one in an empty room fails put 100-1000 into the empty room, it has GOT to work!!! It is too easy to fail! Being in a lab is all that it takes!
I'd suggest you watch this[0], this issue was literally costing human lives, they knew there was a rudder issue, they placed it in a lab, testing it for thousands of hours and ultimately found it by a little luck. It moved our understanding of failure states forward.
There's no reason to assume that finding the issue with the starter motor is easy or trivial. No amount of lab hand waving changes that, it will take just brute effort.
Obviously figuring out which circumstances are the ones that are actually responsible for failures will be more difficult. But it's not too hard to do some sensitivity analysis to get some clues.
If they're highly sensitive to having too much current drawn then that might make you suspect that somehow, somewhere the system's power demands are overwhelming the generator and that's what is causing the failure.
The point behind "it's not rocket science" is that rockets are very, very expensive to make and so you can't just test as many of them as you'd like, for as long as you'd like, until you through trial and error reproduce the conditions that caused the failure. You also don't get the rocket back when it either succeeds or fails.
But in this case the starter/generators are cheap, and they are able to in many cases sort through the debris of the crash. So that does make it qualitatively and quantitatively different than rocket science.
That's very, very different than physical objects.
When software controls hardware, yes things can get weirder. But the software can't cause magical things to happen; the atoms don't rearrange themselves.
Bit flips tend to be much more like magic, if applied to the real world. A wrench doesn't stop working because you swap out a single atom. But software can, if you flip the wrong bit.
> That's very, very different than physical objects.
True... spontaneous changes to the structure of physical objects are quite a bit more likely. One of software's greatest features is that it's not subject to the physical wear that physical tools experience.
Actually if the components catch on fire or something finding out which one shit the bed is by far the easiest part of the entire ordeal, assuming it's not spread over the face of a mountain.
In the case of something like the 737 rudder problem, those planes were designed 40 years ago, in an era when it wasn't practical to record every bit of operating data in real time, or add cheap, lightweight sensors to everything in sight. That's not true anymore. Whether they're building a drone, a fighter plane, a spacecraft, or even a modern passenger car, there is no excuse for requiring people to stand around some wreckage scratching their heads. The onboard controllers should be able to tell them exactly what went wrong. If they can't, then that's the problem to be solved first.
And this can provide incredible amounts of information, and get us closer to the source of issues much faster. Many times, it makes the issue immediately obvious and documented.
HOWEVER! Do NOT make assumptions and fool yourself into thinking this is a cure-all. There are many problems that, while the logged sensor data narrows it down and provides clues, it can sometimes either not provide the critical clues, or can even be misleading. Yes, sometimes adding more sensors focused on the issue may help, but not always.
Sometimes it is just down to the hard work of finding the peculiar circumstances and interactions that cause previously unknown failure modes.
Been there, done that (UAV & motorsport systems), seen lots of very smart & experienced engineers stumped for way longer than you'd expect.