Can you elaborate a bit on how such testing is done, or share a good article on the topic? It sounds like a hard problem to need to get things right this bad, or else.
Not that long ago there was a few HN post about running on the metal that started off with this [0] (also called "Space Shuttle Style). Also speaking of NASA, they - and many other government departments - use a system called Technology Readiness Level (TRL)[1 -image] [2 - 1pg pdf]. This is used enough that you'll see it in HN comments. With humans on board, you are basically aiming for TRL 8. Look at the steps there and you'll quickly see that 4 years is pretty freaking fast. This not only includes code, but hardware. Everything has to be thoroughly vetted. In a typically contract you can go from TRL 1-3 in 6mo. 3-4 in 6mo-1yr. 4-5 in 1-2yrs. And so on. My guess is that the Tesla stuff is closer to TRL 5 or 6, since there is a driver involved. You'd need TRL 8 at level 4/5 to get fully autonomous driving approved. As it should.
As software people I think many will laugh at the low TRL of their own work. It isn't too bad or anything since other sectors need to move fast (probably security people will disagree). But other sectors need to move slow and ensure that things don't break. Because things breaking means people dying.
> As software people I think many will laugh at the low TRL of their own work. It isn't too bad or anything since other sectors need to move fast (probably security people will disagree). But other sectors need to move slow and ensure that things don't break. Because things breaking means people dying.
I doubt more than 5% of developers have ever worked on anything beyond a TRL4. SREs, maybe,
Typically, everything in civil aviation is done to DO-178C. Almost everything we work on is level A, the highest level of criticality. Military stuff is generally much less rigorous, believe it or not.
The issue isn't the actual certification, it's the rapidly changing requirements and the standard for testing most software. There's plenty of libraries and tools I'd colloquially consider TRL 8 or 9 but there are tens, sometimes thousands, of people who can make a change to that software and push an update to millions of systems with little more than a glance from an SRE running `apt-get upgrade.` The nature of network facing software even requires you balance the need to keep your infrastructure stable with the need to keep it secure so you're always stuck in a loop between customers, support, management, developers, and operations where everything constantly changes.
Once software is operational, whether you are following DO-178x/33x, FDA's General Principles of Software Validation and other guidelines, ISO-whatever, or NASA/military TRL, there's a whole ton of stuff you have to do to make any changes once you reach a certain point in development. Since most businesses have the benefit of captive employees that can be woken up in the middle of hte night and terra-locked systems, they never even come close to reaching that point.
it's been a while, do-178 is concerned with software while do-254 is hardware (both for aviation, FAA standards). Depending on the criticality of the component (e.g. engine control vs radios vs entertainment system) they will abide by different levels (ie DO-178A ... DO-178E).
For both software and hardware there will be requirements for documentation, design, verification, and testing. Some even go as far as to requir the implementation of certain functional logic in multiple ways and having concensus logic (eg hardware logic to interpret GPS accuracy/confidence That ends up being broadcast externally).
There's also DO-160 that's concerned with environmental requirements (eg temperature, humidity, lighting).
This is what makes a radio that should cost $300, cost $5000, and why FAA certified aviation components are expensive compared to uncertified components (eg hobby airplane builds).
Parent comment really gives a great overview of the process.
One slight nitpick is that DO-178B or DO-178C are revisions of the standard and the associated criticality is associated with the Design Assurance Level (DAL) from A to E. One would say software is developed to DO-178C DAL B for example.
The DAL is determined before the software is started at the Systems level according to a process described in ARP4754A (Guidelines For Development Of Civil Aircraft and Systems) looking at the system architecture, hazards, and potential mitigations of those hazards, one of which is developing software to a certain DAL.
