The fact is, we're doing things and building equipment that is just too complicated for manual control now. Software is a necessity unless we want to be restricted to fairly simple flying machines. It is a topic that will absolutely have to be thought about.
Not sure I want to sit in a plane where the software is written by Toyota programmers ;-)...if this true what you are saying the planes should be pilot-less then! what is teh use of paying high $ for a guy who can't fly the plane anyways
...to find "agile software development" as part of a talk on flight software! (I guess there's nothing that says all this spaceflight is necessarily "manned" but that's beside the point.) For developing the avionics software used in normal commercial flight every requirement links to a specification item and to the test that verifies the implementation. "Agile" generally refers to a "shoot from the hip" way of doing things, highly intuitive, we'll write a specification about what we wrote "someday if we ever get around to it", we'll just load lots of coders in a room at have them get cracking because none of this requires thinking in advance about methods and strategies, and any approach is as good as any other. Taking an agile approach would actually tend to RAISE the overall cost due to the amount of code that would have to get discarded before ALL the requirements could actually be met! Oh sure there are some code development techniques that can raise "productivity" if KLOCs/week is your "holy grail" (and you never read "The Mythical Man-Month"), and a few that help even if it's not. Do you really want to fly on a commercial aircraft on which the flight control software was "written by the seat of the pants"? Didn't think so.
This is one of the things that disturbs me about agile development. It is often used as an excuse to go into shoot-from-the-hip programming mode. If you really follow the discipline of agile development it can be a very good way to continuously test against requirements. In the case of flight software, if you have a good simulation and test environment then it can be very valid to develop software in that environment in an agile fashion. The key is the capability to automate regression testing rather than just assuming that things are not breaking because you are such a good programmer... :-)
P.S. I was wondering how quickly 'Toyota programmer' would become a pejorative term. I can just about sense the resumes out there being scrubbed.
Actually under DO-178C any tests written by the developers themselves don't "score" because tests need to be written/performed by entities other than those who wrote the code, nor would "automated" tests unless and until the automation "tool" itself becomes a "qualified tool" - I wouldn't hold my breath for that! (It's not clear how much management is generally willing to commit to "non-scoring" testing on any project given how burdensome the required stuff is anyway.) I hope you understand that I'm not foursquare against new development techniques nor would I have any degree of contempt against certain aspects of the legitimate agile process or the individuals who are proficient at it, but you really can't "impose" a development methodology on a certification process and expect it to "conform" to that methodology, it's the other way around as it has to be. It might be useful in the future to set out to define what "safety-critical agile" COULD mean but I believe we're a long ways from being there right now.
Agreed. I have worked in both commercial and military development environments over the years, and highly regulated environments do not change quickly, as you have pointed out. There are areas in those environments, however, where advancements can be given waiver to test. This has been where DARPA in particular has been more open to experimentation than the larger programs. I think at some point we have to recognize that the software development process is evolving and build in a path to integrate that evolution into these processes. This is basically the reason for DARPA existing.
Who all has reviewed this paper on COTS RTOSes by the FAA
It seems as though the potential for some of Toyota's issues exist at the RTOS level in this review of flight code using COTS RTOSes by the FAA -- One has to take this in the context of given a single LRU, one may have 3-4 identical LRU/SRU's duplicating the same functions, thus mitigating many of the potential concerns.
One item that often is overlooked in the SSA is the effects of multiple LRU's simultaneously resetting due to SEU/and Power Integrity, or other issues. This can lead to issues such as aeroelastic flutter on control surfaces, or other issues such as hard-over conditions --- which have to be mitigated via system and mechancial design methods.