Menu Sign In Contact FAQ
Banner
Welcome to our forums

Aspen EFD and MFD repeatedly resetting in flight

Peter wrote:

Yes they are not validating the data properly (or at all).

This in itself is unbelievable. Doesn’t the development standard certified avionics software (DO-178B/C) say anything about testing input data?

(When I was a student around 1980, a common joke was to stress test software by hammering away at the keyboard making rapid, large random inputs. This actually caused a surprising number of software systems to crash.)

ESKC (Uppsala/Sundbro), Sweden

Though that was more often timing issues than data.

When Object Orienting Programming first came out, and we hadn’t yet fully embraced and understood it, it was amazingly difficult to track down some really abberent behaviour caused by process timing (ie mostly an object finding that the environment had been changed by another process while it was away processing. Imagine, for example, the record locking issues when hundreds of thousands of people are trying to buy a hundred thousand arena concert tickets at the very moment it went on sale.)

EGKB Biggin Hill

Doesn’t the development standard certified avionics software (DO-178B/C) say anything about testing input data?

I think the weak link here is that certified avionics are not required to be tested with stuff other than what is certified to connect to it. There is no general requirement to make input ports bulletproof. But… you don’t have control over what data is coming out of that other stuff

I’ve been doing software since the early 1980s. I think the main reason for these vulnerabilities is the loss of “low level competence” among programmers. I am avoiding the use of “developer” and especially “software architect” which is what you call yourself on Crystal Maze

When you program in assembler, you “obviously know” that if you have a 100 byte buffer for input data then the 101th byte will corrupt something, and usually you know exactly what it will corrupt. So you range check the pointer, and probably sanity-check the data too.

The problem is that, in assembler, productivity is very low, plus nowadays it is near-impossible to find good programmers (they are now mostly in the former USSR ) and anyway most consumer-facing products of today are so complex you would finish them a decade after the market opportunity has moved on.

Accordingly, for many years and really since the 1980s, the best embedded-system programmers have been using C, with maybe bits of assembler where needed. This is also pretty direct so – by the time you have been doing it for some years – you tend to know where the skeletons are likely to be buried. Still, the use of pointers (as opposed to explicit arrays) in C is responsible for the majority of bastard-to-find bugs…

The real problems started with collaborative (team) programming which drove C++ and the use of libraries for everything. These deliver great productivity for today’s “get it out there and fix the bugs later, preferably in the next $$$ version” world. Today, and for many years past, the programmer has no idea of sanity checking, and much of the time there isn’t any. The I/O stuff is hidden deep in some library which he is calling (and which was likely to have been written by some other muppet) and for which the sources are not available. Plus he probably is new to the game, never having got his hands dirty with “real bytes”. Look at how many years it has taken Micro$oft to get hundreds (probably thousands) of invalid-packet back-door vulnerabilities out of windows… such an obvious thing, always has been, but it is equally obvious that their programmers had little idea of the full extent of the problem, it being hidden deep in various C++ libraries which everybody was blindly using and re-using.

I don’t know about Aspen but some avionics use Embedded NT. Previous thread

Administrator
Shoreham EGKA, United Kingdom

hmmm…..

When you think about it, the history of programming is not dissimilar to the history of piloting.

In the tens and twenties pilots flew in assembler.
In the thirties and forties they flew C
For the next forty years they flew C++
Then along came Visual Basic, Lisp, Java and Python and now there is an almost complete disconnect between the information they have in the cockpit and molecules that are flowing over their aerofoils.

EGKB Biggin Hill
I think the weak link here is that certified avionics are not required to be tested with stuff other than what is certified to connect to it. There is no general requirement to make input ports bulletproof. But… you don’t have control over what data is coming out of that other stuff

Sure, but programmers who don’t check all input data at least for syntactic correctness in a critical application should be shot. Or at least tarred and feathered.

The real problems started with collaborative (team) programming which drove C++ and the use of libraries for everything. These deliver great productivity for today’s “get it out there and fix the bugs later, preferably in the next $$$ version” world. Today, and for many years past, the programmer has no idea of sanity checking, and much of the time there isn’t any. The I/O stuff is hidden deep in some library which he is calling (and which was likely to have been written by some other muppet) and for which the sources are not available. Plus he probably is new to the game, never having got his hands dirty with “real bytes”. Look at how many years it has taken Micro$oft to get hundreds (probably thousands) of invalid-packet back-door vulnerabilities out of windows… such an obvious thing, always has been, but it is equally obvious that their programmers had little idea of the full extent of the problem, it being hidden deep in various C++ libraries which everybody was blindly using and re-using.

I am convinced that the problem is lack of proper training. If you have a degree in Computer Science or Software Engineering from a decent university, then you definitely know about these things. But the demand for programmers today mean that many people have had very short training. This includes university graduates with majors in other subjects who get a programming job because that’s where the jobs are.

(Yes, of course some university graduates are poor programmers and some self-taught persons are great. But I am talking about the typical case.)

ESKC (Uppsala/Sundbro), Sweden

I am afraid that “computer science” is not wot it used to be in the 1970s, when you did CPU registers, the accumulator, etc. I recall going on a date with a girl c. 2000 who had just finished a computer science masters and she got as far as java, php, javascript… so the rot goes back many years.

Also those 1970s and 1980s people cut their teeth on 8080/6502/Z80/etc assembler because that’s all there was. Today you can skip all that. And no employer is going to be training low level programming.

And what you did at univ becomes irrelevant within months of leaving – because you forgot it, and your first job doesn’t use any of it. Very few graduates go into a job which is a match for their skills or ambitions. Most end up doing crap jobs, just short of sweeping the office floor. But then most graduates are, and always have been, unemployable…

Also people in some sectors of the US technology business move on fairly quickly. I recall one old friend who went to work for a company in California telling me how the standard of living of programmers is so high. They can go surfing at the weekends or even after work, so The Job is not really a big feature of their life. If you make it too hard, they will just take a walk.

but programmers who don’t check all input data at least for syntactic correctness in a critical application should be shot

I suspect that you would then have to certify the input checking doesn’t do any harm… The relevant detail might be that you licensed some confidential protocol document, maybe even got some library to implement it…

Administrator
Shoreham EGKA, United Kingdom

Peter wrote:

I am afraid that “computer science” is not wot it used to be in the 1970s, when you did CPU registers, the accumulator, etc.

I entered the “CS scene” in the late 1970s, first taught at the university in the early 1980s and today (after some detours in research institutes and industry) still teach at the university. I can assure you that students still learn about CPU registers. At my university CS bachelor students do that already in their first year.

I grant you that there can be a major difference between what students learn at a research university compared to a regional university college, but that only underlines my point that we have lots of programmers with poor training and thus poor understanding of what they really are doing.

ESKC (Uppsala/Sundbro), Sweden

Timothy wrote:

When Object Orienting Programming first came out, and we hadn’t yet fully embraced and understood it, it was amazingly difficult to track down some really abberent behaviour caused by process timing

That’s not a side effect of OOP, it’s a side effect of a parallel system (whatever it may be – a multithreaded program, several programs working on the same thing, etc). It’s still far from a solved problem, and things like race conditions can be very difficult to track down even if you’re writing in straight C. Thread safety is still a massive issue today whether you use OOP or not.

There are some languages designed explicitly for parallelism, such as Erlang, which make it less error prone.

Andreas IOM

alioth wrote:

That’s not a side effect of OOP, it’s a side effect of a parallel system (whatever it may be – a multithreaded program, several programs working on the same thing, etc).

As you say, OOP is orthogonal to parallelism. In fact the first major object-oriented programming language (SIMULA) was designed in the mid-1960s long before parallel programming was common even in the academic community. Interestingly, it featured co-routining which is a pseudo-parallel control structure.

ESKC (Uppsala/Sundbro), Sweden

Aspen restart failure with ADSB in Germany

A while ago Aspen had the problem, that some incoming ADSB-In-Weather signals caused a restart problem on the unit. As ADSB-weather is normally not supported in Europe, that was no problem. But since Garmin has installed their ADSB-Weather-Broadcaststation at Friedrichshafen it became a problem. We had this on our flight to Greece, the Lynx got the signaI and the Aspen restarts. I will update the software next time, when being at maintenance.

EDDS , Germany
Sign in to add your message

Back to Top