Replies

Last night was the season premier of NCIS.

I understand that I am not on the cutting edge of self-teaching software, but I’m afraid I will remain skeptical on its utility in aerospace.

The very concept of “develop (ad hoc), decouple, and thoroughly test” is well below the minimum requirements for process as they are currently written. I don’t see that changing any time soon - and I am on the committe working on the next generation of guidance on the subject.

To my knowledge, there have been very few aircraft incidents caused by software. I think I heard of a single one, but human memory is frail. To radically change what works - what makes for a high degree of safety in the fielded systems - doesn’t make all that much sense, especially when doing so requires adoption of unproven technology.

And, before you protest my choice of the word “unproven”, consider that the aerospace industry is just now coming to grips with OOT. We’re behind the times, but people stay alive...

Have a great day, Roger.

The very concept of “develop (ad hoc), decouple, and thoroughly test” is well below the minimum requirements for process as they are currently written.

I realize that there's quite a bit of work to do to disseminate information. Providing an overview of engineering approaches to meet a variety of situations was just my idea of a way to get started; kind of like the introductory chapter.

I've been working with people more involved with genetic programming. "Fitness functions" are used to define what the finished algorithm is supposed to do. There is no reason I can think of why the process of developing and maintaining the fitness functions should not be the same as in traditional development. The "fitness functions" are themselves, programs - designed to work with a learning engine to produce a result. Input - program - output.

The fitness functions themselves can also include restraints; i.e. you can also specify what results are not allowed to do. So far, it's still quite traditional - except that reviewed and approved detailed requirements go directly into a program that engineers what the requirements tell it to produce.

Results are not just a black box filled with 1s and 0s. They can be produced in the form of more traditional high level language structures, and you can pick apart and analyze results any way that you with - testing at functional through systems level.

A particular area of interest to me and HLL; is the blending of evolution and design - i.e. automated machine learning and traditional fixed processes for structure and "high level" control. Safety assurance is one of the fundamental motivations for this interest.

But I'm getting ahead of the current state of the HLL project - in which machine learning hasn't even been mentioned yet, and isn't on the current issues list. I do expect to blog on the subject sometime during the next 3 months or so; but I'll be (pleasantly) surprised (and probably happy to the point of excitement) if any demonstration of such emerges during that time. -- on the other hand - if other things are done in good time, I have been considering throwing in a simple demonstration using a relatively simple open-source gp engine - at least enough to show the mechanism of blending the two.