Moderators: richierich, ua900, PanAm_DC10, hOMSaR

 
A330Fan
Topic Author
Posts: 197
Joined: Sun Aug 14, 2005 6:36 pm

Boeing/Airbus FMCs

Wed Aug 31, 2005 9:39 am

Hey, kind of "out there" but here goes:

Would anyone have any information about the software programming and design that goes into the FMC for Boeing and/or Airbus aircraft?

Is the FMC designed by the company and do they program the FMCs themselves with their own teams of software engineers or do they contract software engineers from the outside for this purpose?

Any other random info such as, programming language or any sort of information would be appreciated!!

As we all know the programming code within the FMCs must be extremely well written as the FMCs are a "mission critical" device and any bugs within the software could be detrimental to the aircraft's safety (while using the FMC).

The reason why I am asking this is the fact that I am a computer science student and an aviation enthusiast so this is something that really interests me and from being on this site, it seems that chances are, someone might have some info!!

Thanks in advance,
Patrick.
 
User avatar
zeke
Posts: 17397
Joined: Thu Dec 14, 2006 1:42 pm

RE: Boeing/Airbus FMCs

Wed Aug 31, 2005 11:21 am

Patrick,

Boeing and Airbus do not make FMC's, they are produced by third parties, popular ones are from Honeywell and Smiths.

Airlines do not vary the software in the FMC, they do however get specific databases for their area of operations (the database has the runways, airports, nav aids etc).

The databases are supplied by approved third parties, such as Lido or Jeppesen, the airline cannot vary the database, that needs to be done by an approved controlled source.

FMCs are very low powered computers, some of them have maximum database capacities of 256 kb, the technology in them is very outdated.
 
Woodreau
Posts: 2315
Joined: Mon Sep 24, 2001 6:44 am

RE: Boeing/Airbus FMCs

Wed Aug 31, 2005 10:05 pm

Here's a link to the FMS page at Honeywell, who makes the FMC for Boeings and A330/A340/A380 and is trying to market itself to upgrade the older Airbuses.

http://www.honeywellaes.com/servlet/...etSgmt=AIRTRANSPORT&ProductType=AT

Then scroll down the page until you get to FMS.

The processor used in the Honeywell FMS's is the AMD 29050 processor running at a whopping 24MHz.
 
A330Fan
Topic Author
Posts: 197
Joined: Sun Aug 14, 2005 6:36 pm

RE: Boeing/Airbus FMCs

Wed Aug 31, 2005 10:32 pm

Thanks guys!!

Quoting Woodreau (Reply 2):
The processor used in the Honeywell FMS's is the AMD 29050 processor running at a whopping 24MHz.

Yeah, thats really something!!!  rotfl  It just goes to show you (compared to home/business PCs) how the technology differs! Suprised it isn't an intel chip running inside there!

Thanks for the link btw!! Exactly what I was looking for!
 
User avatar
Starlionblue
Posts: 21180
Joined: Fri Feb 27, 2004 9:54 pm

RE: Boeing/Airbus FMCs

Wed Aug 31, 2005 10:59 pm

Quoting A330Fan (Reply 3):

Quoting Woodreau (Reply 2):
The processor used in the Honeywell FMS's is the AMD 29050 processor running at a whopping 24MHz.

Yeah, thats really something!!! rotfl It just goes to show you (compared to home/business PCs) how the technology differs! Suprised it isn't an intel chip running inside there!

Well, it could just as well be an IBM processor. This computer has no graphics and doesn't really do very much. Performance is probably more than enough for the job. Priority is on reliability. A low powered processor will not need a fan and will use very little power.
 
A330Fan
Topic Author
Posts: 197
Joined: Sun Aug 14, 2005 6:36 pm

RE: Boeing/Airbus FMCs

Thu Sep 01, 2005 2:24 am

Quoting Starlionblue (Reply 4):
Well, it could just as well be an IBM processor. This computer has no graphics and doesn't really do very much. Performance is probably more than enough for the job. Priority is on reliability. A low powered processor will not need a fan and will use very little power.

Thats what I'm saying... So little power needed for such an important device!
 
User avatar
Starlionblue
Posts: 21180
Joined: Fri Feb 27, 2004 9:54 pm

RE: Boeing/Airbus FMCs

Thu Sep 01, 2005 4:44 am

Quoting A330Fan (Reply 5):
So little power needed for such an important device!

You'd think the rest of the computer industry would take notice. A server runs on average at 5-10% CPU utilization. Talk about wasted space.
 
User avatar
Jetlagged
Posts: 2564
Joined: Sun Jan 23, 2005 3:00 pm

RE: Boeing/Airbus FMCs

Sat Sep 03, 2005 9:51 am

Quoting Zeke (Reply 1):
Airlines do not vary the software in the FMC, they do however get specific databases for their area of operations (the database has the runways, airports, nav aids etc).

On the 747-400 (and probably other Boeings), each airline has it's own operating program for the FMC which is installed to customise the performance model, configuration and so on. So in that sense the airline does program the FMC. The basic FMC software does not change from airline to airline and is proprietary to Smiths, Honeywell, Sfena, etc. Unlike the navigation database, the operating program does not change each month, so only needs to be updated as required.

Program pins also configure the FMC, amongst other things, according to airline option requirements.
 
User avatar
zeke
Posts: 17397
Joined: Thu Dec 14, 2006 1:42 pm

RE: Boeing/Airbus FMCs

Sat Sep 03, 2005 11:19 am

Quoting Jetlagged (Reply 7):
So in that sense the airline does program the FMC.

No they don't, nor do they do program pin changes. These are not airline functions, these are functions of manufacturers of the aircraft or FMC.

Pin changes and database updates can be made by maintenance people, however these are done in accordance with manufactures instructions.

No user defined data is to installed on a FMC, has to come from a controlled source, an airline is generally not a controlled source (some airlines like LH have a subsidiary like Lido that is a controlled source). If you want an EOSID, you have to go to your database supplier to have it included, an airline cannot do that.
 
User avatar
Jetlagged
Posts: 2564
Joined: Sun Jan 23, 2005 3:00 pm

RE: Boeing/Airbus FMCs

Mon Sep 05, 2005 1:18 am

Quoting Zeke (Reply 8):
No they don't, nor do they do program pin changes. These are not airline functions, these are functions of manufacturers of the aircraft or FMC.

What I was trying to point out is that there is quite a lot of customisation available across different operators. If an operator acquires a used aircraft their own customisations would be applied, not by the aircraft manufacturer or the supplier of the FMC, but by the operators maintenance staff. Clearly new aircraft would be properly configured by the manufacturer before delivery.

If the operating program for an operator is revised it would be installed by maintenance personnel (they have the necessary disks).

This isn't programming in the usual sense of course, but it isn't true to say that all FMC software in 747-400 aircraft is identical for all airlines.
 
dl757md
Posts: 1483
Joined: Mon May 24, 2004 9:32 am

RE: Boeing/Airbus FMCs

Mon Sep 05, 2005 6:44 am

There are three software components to an FMC

  • Operation software - determines which sensors are used for internal
    computations, how the computations are performed and programs any errors
    from the selected lateral and vertical profile into steering requests to maintain
    the selected route. This software is input via connectors on the front of the FMC in the MEC. Is only updated by engineering authorization.
  • navigation database - used to define route selection and contains airports, procedures, way points, navaids, etc., This portion of the internal data is input and updated by a portable data base loader and connectors in the flight deck area.
  • Performance database - defines the dynamic characteristics of an airframe/
    engine combination in a specific environment.


At DL the Op software is only updated after DL engineering has approved the need for an update usually after an update is issued by the manufacturer.

The Nav database is updated once a month.

The performance database is updated only to reflect major aircraft configuration changes i.e. change in MTOW, re-engineing with different engines, addition of winglets, etc.. Obviously this doesn't happen very often.

For clarification the actual data loads are performed by AMTs using portable data loaders with disks prepared by the above authorities.

The 737NG, 764 and 777 have airborne data loaders.

Dl757Md
 
User avatar
zeke
Posts: 17397
Joined: Thu Dec 14, 2006 1:42 pm

RE: Boeing/Airbus FMCs

Mon Sep 05, 2005 4:51 pm

Dl757md,

100% correct.

Jetlagged I think you maybe thinking of changing like the SITA logon for ACARS, or tail number performance penalties. These are minor changes done by airline maintenance mechanics.

I have picked up aircraft from the factory, one of the first things that is done when reaching out base is to changes the FMC database and tail number performance fuel burn increase so predictions on the FMC are the same as our flight planning software.

For us, any database or other software loaded onto the FMC always come from an external party.
 
User avatar
Jetlagged
Posts: 2564
Joined: Sun Jan 23, 2005 3:00 pm

RE: Boeing/Airbus FMCs

Tue Sep 06, 2005 5:30 am

No, what I'm thinking of is what the airline engineering dept. referred to as the operating program. This came on floppy disks, just like the navigation database updates.

I hadn't been aware of it's existence before my company moved a 747-400 flight simulator (which used aircraft FMCs and CDUs) from one airline to another. We assumed that by correctly assigning program pins the ident screen would show the correct information, but it refused to do so, showing 747-400D and an incorrect thrust rating. The airlines engineering department supplied us with their operating program disks which we installed. Lo and behold the correct ident page using the right thrust rating appeared after powering off/on.

This may be unique to the 747-400. It may also be to do with PAX/Cargo differences.
 
bri2k1
Posts: 952
Joined: Sun Dec 19, 2004 4:13 am

RE: Boeing/Airbus FMCs

Tue Sep 06, 2005 5:35 am

Quoting A330Fan (Thread starter):
Any other random info such as, programming language

Mission-critical, highly-specialized systems such as these are most often programmed in pure assembly language; that is, binary instructions directly accessing the functions of the particular processor on which the code will reside. This allows writing bug-free optimized code, utilizing the minimum amount of memory and minimum set of processor instructions per call, reducing overhead and CPU utilization. There's no compiler or anything like that; you just write the low-level instructions directly. It's very tedious work.

As a CS student, you should (if you haven't already) take an assembly language course. They're often called Computer Architecture courses, because you must first learn about the detailed components of processor and memory structures before learning how to write code to manipulate them directly.
 
User avatar
Jetlagged
Posts: 2564
Joined: Sun Jan 23, 2005 3:00 pm

RE: Boeing/Airbus FMCs

Tue Sep 06, 2005 11:41 pm

In my programming experience, assembler language is almost guarranteed to provide you with bugs, and much harder ones to track down at that. The cleverer and more efficient the programmer tries to be, the worse this situation gets.

Agreed it is likely to make the most efficient code, but these days memory and processing power is cheap, unlike when FMCs were first introduced.

Often the approach taken is to write different lanes in different programming languages to the same program specification. This means that the same bug can't be present in all lanes, assuming the spec itself is bug free  Smile
 
A330Fan
Topic Author
Posts: 197
Joined: Sun Aug 14, 2005 6:36 pm

RE: Boeing/Airbus FMCs

Fri Sep 09, 2005 6:16 am

Quoting Bri2k1 (Reply 13):
As a CS student, you should (if you haven't already) take an assembly language course.

I did a small amount of assembly language programming at the end of this year (april/may) and starting next week i'll be doin a proper course in it!!
 
Klaus
Posts: 21761
Joined: Wed Jul 11, 2001 7:41 am

RE: Boeing/Airbus FMCs

Sun Oct 16, 2005 2:20 am

Quoting Jetlagged (Reply 14):
In my programming experience, assembler language is almost guarranteed to provide you with bugs, and much harder ones to track down at that.

Not really.

The primary difference to higher-level language is that assembly language removes all hidden factors from the equation - you can directly identify everything in the binary code and data.

Compilers can be verified, but they include so much overhead and hidden complexity that it can be very complex and expensive to do so. Assemblers are much easier to verify and much easier to get to the reliability level you may desire.

Assembly language is more demanding in several respects, but it is also more precise and more controllable than higher-level languages.

It surely bites your head off if you're habitually sloppy, but If you actually work diligently and and verify your code (by tracing it, for instance), there is no major penalty involved.

Quoting Jetlagged (Reply 14):
The cleverer and more efficient the programmer tries to be, the worse this situation gets.

No. Clever programmers and "clever" ones are a world apart, same as in most other professions...
 
User avatar
Jetlagged
Posts: 2564
Joined: Sun Jan 23, 2005 3:00 pm

RE: Boeing/Airbus FMCs

Sun Oct 16, 2005 4:20 am

Quoting Klaus (Reply 16):
The primary difference to higher-level language is that assembly language removes all hidden factors from the equation - you can directly identify everything in the binary code and data.

I'd agree with you that C, for example, can be incredibly hard to debug, depending on how well structured the source code is. Unstructured high level code is no easier to deal with than assembler. Bad design can exist in assembler language code too, creating problems which are not immediately obvious. In my field (real time simulation) the only problems I have seen with compilers are highly optimised ones. If forced to use something like that I might switch back to assembler  Smile Switch off the optimisation options and you are left with less efficient but faithful object.

Of course, if you are having problems with a piece of compiled high level language program you can always check the object code it produces.

Quoting Jetlagged (Reply 14):
In my programming experience, assembler language is almost guarranteed to provide you with bugs, and much harder ones to track down at that. The cleverer and more efficient the programmer tries to be, the worse this situation gets



Quoting Klaus (Reply 16):
No. Clever programmers and "clever" ones are a world apart, same as in most other professions...

I stand by my paragraph as a whole. If you want to be "clever" with the use of the word "clever" that's up to you.
 
Klaus
Posts: 21761
Joined: Wed Jul 11, 2001 7:41 am

RE: Boeing/Airbus FMCs

Sun Oct 16, 2005 8:01 am

Quoting Jetlagged (Reply 17):
Of course, if you are having problems with a piece of compiled high level language program you can always check the object code it produces.

In principle, yes; But the most difficult class of problems is the one you aren't even aware exist in your code. In many cases those are high-level conceptual or design issues, but in many cases people are tempted to simply overlook some of the "nuts and bolts" problems their implementation may encounter.

Assembly language is certainly not a perfect solution, but it can help being more in control and being more aware of what's really going on than with any other language...

Quoting Jetlagged (Reply 17):
I stand by my paragraph as a whole. If you want to be "clever" with the use of the word "clever" that's up to you.

No, the difference between those who actually know what they're doing (and where to be very, very cautious) and those who just think they do and subsequently make the worst mistakes is essential - in any kind of profession.
 
User avatar
Jetlagged
Posts: 2564
Joined: Sun Jan 23, 2005 3:00 pm

RE: Boeing/Airbus FMCs

Sun Oct 16, 2005 8:56 am

Quoting Klaus (Reply 18):
But the most difficult class of problems is the one you aren't even aware exist in your code. In many cases those are high-level conceptual or design issues, but in many cases people are tempted to simply overlook some of the "nuts and bolts" problems their implementation may encounter.

Certainly it is difficult to fix a problem you are not aware of. How does assembler language help with this? If the software meets it's specification fully and does not cause undesirable issues then it's essentially problem free. That does not mean it has no latent bugs which might surface in the next development cycle. But this can occur in even the most meticulously designed assembler code.

It's horses for courses. There are applications for which assembler language used to be the only solution in the past due to constraints of memory and time. Because of greater computing power, high level languages can offer an alternative, which is easier to write, easier to debug and easier to maintain. Assembler language is none of those things. I spent years writing the stuff so I know what I'm talking about. There may be certain critical applications where precise control of the code is essential, but these are few and far between.

Certainly assembler language will much take longer to design, code and test. If you are producing applications in large numbers this is not a problem long term. But in situations where development is rapid and unit numbers are low, assembler code is a big handicap.

Let's get this clear, I'm not talking about Visual C, Visual Basic, any kind of auto generated code, etc, where documentation is poor and you have no real control.

Regarding this difficult last paragraph, you are being very correct and I can't argue with your sentiments. However you are missing my point. Sometimes very good programmers take too much pride in writing ever more economical code, which becomes increasingly hard to understand. You're saying that if they do that they aren't good programmers. Maybe so, but they would argue they were being very efficient. I've seen people come back to a piece of code they wrote after six months and have to admit they have no idea how it works. They aren't bad programmers and the software works fine, but the code is poor by virtue of being unreadable.
 
Klaus
Posts: 21761
Joined: Wed Jul 11, 2001 7:41 am

RE: Boeing/Airbus FMCs

Mon Oct 17, 2005 2:17 am

Quoting Jetlagged (Reply 19):
Certainly it is difficult to fix a problem you are not aware of. How does assembler language help with this?

The specifications of most higher-level languages are relatively sloppy and weaken the programmer's awareness about the pitfalls involved.

One of those points is range and overflow checking. In assembly it is very obvious how to do range checks and where and how within an expression to check for overflows. The language specification explicitly specifies the exact consequences and side effects of every single instruction (well, that is if you don't count Intel manuals - the Intel CPU manuals I've seen are the only ones so far which managed to stay vague about the exact specifications).

In most high-level languages it is both difficult and tedious to keep track of and to recognize the exact impact of range checks and overflows in every single step. There simply is no overflow or carry flag on source code level in C or in most other languages and they are relatively difficult to emulate; On top of that, a single-line expression can have multiple pitfalls depending on how it's parenthesized and optimized by the compiler. Tricky stuff that requires much more attention than the average programmer usually applies...

Quoting Jetlagged (Reply 19):
Sometimes very good programmers take too much pride in writing ever more economical code, which becomes increasingly hard to understand. You're saying that if they do that they aren't good programmers. Maybe so, but they would argue they were being very efficient. I've seen people come back to a piece of code they wrote after six months and have to admit they have no idea how it works. They aren't bad programmers and the software works fine, but the code is poor by virtue of being unreadable.

That is the primary problem with 99% of all programmers in the industry:

If you're doing something clever, document it. If you can't clearly and precisely document it, it's not clever but it's just an accident waiting to happen.

The consequence for most programmers is that they rather don't document anything unless they're threatened most severely...

The result is the dismal code quality that's an industry-wide problem today.

Fortunately developers in the aviation field (and in other high-safety areas) work to somewhat higher specs, but it's the very rare exception to the depressing rule.

Just look at the Windows mess, but the Open Source community has its own variation (this time with clearly visible and usually embarrassing source code) and "even" Apple has its good share of mistakes, bugs and problems despite somewhat higher standards (primarily on the conceptual level, but also, thankfully, regarding documentation).
 
Klaus
Posts: 21761
Joined: Wed Jul 11, 2001 7:41 am

RE: Boeing/Airbus FMCs

Mon Oct 17, 2005 2:36 am

Quoting Klaus (Reply 20):
If you're doing something clever, document it.

Just for clarification: All code must be documented. It just gets even more essential with "tricky" code.
 
User avatar
Jetlagged
Posts: 2564
Joined: Sun Jan 23, 2005 3:00 pm

RE: Boeing/Airbus FMCs

Mon Oct 17, 2005 8:11 am

Quoting Klaus (Reply 20):
The specifications of most higher-level languages are relatively sloppy and weaken the programmer's awareness about the pitfalls involved.

Unless you are experienced with the language. But that is the case with assembler language too: you can't code to the standards necessary unless you are very familiar with it. At least high level languages protect inexperienced programmers from themselves by eliminating most errors at the compilation stage (which just leaves design errors the compiler can't possibly see). With assembler, the programmer has no such assistance.

Quoting Klaus (Reply 20):
There simply is no overflow or carry flag on source code level in C or in most other languages and they are relatively difficult to emulate

If you are working in floating point, then overflow is very unusual and carry flags are not required. That's not to say you can't overflow (or underflow), just that the range of numbers available to you is sufficiently large for all practical purposes. Most operating systems have arithmetic exception handling you can switch on (with varying degrees of success) in case you do get over- or underflow. I agree it is very easy when working in fixed point at high level to forget about overflow, etc.

Some high level languages have built in range checking so you can't exceed limits (you define the limits when you define the data type). At one point the US DoD insisted all software delivered to it would be written in ADA (which has range checking), so assembler would not be admissable. I'm not sure if this is still the case, but I would guess that as a result most military avionics units are programmed in ADA.

I'm not saying high level is better than low level for everything, but I'm a great advocate of readable source code. Documentation can go missing.

I originally posted about high level languages in response to this post:

Quoting Bri2k1 (Reply 13):
Mission-critical, highly-specialized systems such as these are most often programmed in pure assembly language; that is, binary instructions directly accessing the functions of the particular processor on which the code will reside. This allows writing bug-free optimized code, utilizing the minimum amount of memory and minimum set of processor instructions per call, reducing overhead and CPU utilization.

because (a) these days it is not necessary to optimise code that much and (b) assembler language can be as bugged or bug free as any other. The only way I've experienced a compiler introducing bugs was with optimisation switched on.

I don't know about the code in most FMCs, but autopilots and other avionics are quite commonly coded in high level languages. When I started in simulation assembler language was the only code efficient enough to run in real time. Now all flight simulators I know of are coded in high level languages.

I'd be interested to know what kind of applications you develop and why assembler is the only option.
 
Klaus
Posts: 21761
Joined: Wed Jul 11, 2001 7:41 am

RE: Boeing/Airbus FMCs

Tue Oct 18, 2005 9:34 pm

I don't claim that assembly language was generally superior to high-level languages. I just had to respond to the initial statement that assembler code was generally more dangerous and more buggy on principle.

There are quite a few obvious disadvantages, but there are advantages as well if used properly...

In the end the essential differences lie in the way developers use (or misuse) those tools, not in the tools themselves.

Quoting Jetlagged (Reply 22):
If you are working in floating point, then overflow is very unusual and carry flags are not required.

True. But in safety-critical environments you will need a verified floating point unit. The infamous Intel FDIV-bug has illustrated the risks involved. Integer and fixed point operations are much simpler and easier to verify reliably. Many if not most control applications use fixed point math instead of floating point.

Quoting Jetlagged (Reply 22):
Some high level languages have built in range checking so you can't exceed limits (you define the limits when you define the data type).

You will still need to handle those dynamic cases where range is exceeded, although I agree it's a step forward.

Quoting Jetlagged (Reply 22):
I'm not saying high level is better than low level for everything, but I'm a great advocate of readable source code. Documentation can go missing.

That is the big fallacy.

Readable source code has very little to do with good documentation.

Readable source code only tells you how things are being done - good documentation explains why they are being done in the first place and what the concepts behind the code are. And that this distinction is generally not understood is the whole problem which has led to the mess we're in, for the most part.

Substandard code readability is at worst a nuisance - but missing documentation makes the affected code ultimately worthless because concepts and semantic dependencies are lost, often beyond recovery in more complex systems.

Quoting Jetlagged (Reply 22):
because (a) these days it is not necessary to optimise code that much and (b) assembler language can be as bugged or bug free as any other. The only way I've experienced a compiler introducing bugs was with optimisation switched on.

I remember at least two compiler bugs even with all optimizations switched off. And the "opacity" of the compilation process makes it rather difficult to find the cause in such cases.

Quoting Jetlagged (Reply 22):
I'd be interested to know what kind of applications you develop and why assembler is the only option.

In some applications it is. Such as real-time applications with constrained cost, footprint, power, latency and reliability requirements. (In my case not aviation-related, however.)

In most other applications I use high-level languages as well, but it is still good to have a clear understanding what's going on under the hood.
 
User avatar
Jetlagged
Posts: 2564
Joined: Sun Jan 23, 2005 3:00 pm

RE: Boeing/Airbus FMCs

Wed Oct 19, 2005 12:14 am

Quoting Klaus (Reply 23):
I just had to respond to the initial statement that assembler code was generally more dangerous and more buggy on principle.

I didn't say it was more dangerous, nor that it is more buggy in principle. I did not claim assembler programs end up full of bugs, just that you will get a lot more to fix along the way  Smile

Quoting Klaus (Reply 23):
That is the big fallacy.

Readable source code has very little to do with good documentation.

I didn't say it did. If the code is obscurely written, then good documentation is essential. If code is well written and commented then you can get by if the documentation is missing, because all you need to know will be in the code and comments.

Quoting Klaus (Reply 23):
Substandard code readability is at worst a nuisance - but missing documentation makes the affected code ultimately worthless because concepts and semantic dependencies are lost, often beyond recovery in more complex systems.

Have you ever tried to maintain someone else's badly written code? It's more than a nuisance, it costs time and money, and may impact safety. Conversely lack of documentation does not necessarily make the software worthless, but there may be an uneconomic cost to rectify the situation.

Quoting Klaus (Reply 23):
Such as real-time applications with constrained cost, footprint, power, latency and reliability requirements. (In my case not aviation-related, however.)

I have been writing and modifying aviation related real time software applications for nearly 30 years. The constraints you list all apply. Assember language is not used much in my field, for all the reasons I have given.

I don't doubt your skill, knowledge or experience. Please have the courtesy not to doubt mine.
 
Klaus
Posts: 21761
Joined: Wed Jul 11, 2001 7:41 am

RE: Boeing/Airbus FMCs

Wed Oct 19, 2005 1:15 am

Quoting Jetlagged (Reply 24):
I did not claim assembler programs end up full of bugs, just that you will get a lot more to fix along the way

Not necessarily... Above all there are different classes of errors to be made in each environment. In my experience the volume is not that different and well-verified assembly code is more stable and more reliable than high-level code. But less readable and "somewhat" less portable, of course... Big grin

Quoting Jetlagged (Reply 24):
If the code is obscurely written, then good documentation is essential. If code is well written and commented then you can get by if the documentation is missing, because all you need to know will be in the code and comments.

No, that's exactly my point. If documentation merely tells you how the code is operating, it's basically redundant. And since that's the only purpose most programmers can think of, they simply don't do documentation.

The kind of documentation I habitually add to the code describes primarily why the code is doing what it does at that point, in that function or in that module. And that is information that is very difficult to reconstruct even if the code by itself is perfectly well-structured, nicely readable and still badly maintainable because its entire conceptual design has only once existed in the brain of its developer but nowhere else (and it usually fades away even there over time).

It is not that problematic in very small or very simple projects, but most developers miss the train on conceptual documentation when their projects stop being small or trivial.

Quoting Jetlagged (Reply 24):
Have you ever tried to maintain someone else's badly written code?

I'm doing it all the time. And on top of that I'm pretty sure I've made almost every mistake myself a programmer can possibly make. I'm just trying to stop making the most aggravating ones again and again. My documentation style is ultimately just a result of being unable to fully understand my own code again after a few months or years have passed...

Quoting Jetlagged (Reply 24):
Conversely lack of documentation does not necessarily make the software worthless, but there may be an uneconomic cost to rectify the situation.

The lack of conceptual documentation is highly dangerous because if often leads to subsequent mistakes when conceptual assumptions (in the absence of actual documentation) clash between the original implementer and someone who's trying to interface with the code. Conceptual drift, creeping inconsistencies and a host of other ugly effects are almost inevitable in any larger, more complex project that lacks proper (or at least usable) conceptual documentation...

Quoting Jetlagged (Reply 24):
I have been writing and modifying aviation related real time software applications for nearly 30 years. The constraints you list all apply. Assember language is not used much in my field, for all the reasons I have given.

They obviously don't to the same point. When you still have the option to switch to the next-larger CPU derivative in order to be able to use bulkier and slower code, things are a bit different.

Quoting Jetlagged (Reply 24):
I don't doubt your skill, knowledge or experience. Please have the courtesy not to doubt mine.

I don't. From my own experience I just come to slightly different conclusions.

Quoting Jetlagged (Reply 24):
The glass isn't half empty, or half full, it's twice as big as it needs to be.

Perfect!  bigthumbsup 
 
User avatar
Jetlagged
Posts: 2564
Joined: Sun Jan 23, 2005 3:00 pm

RE: Boeing/Airbus FMCs

Thu Oct 20, 2005 11:49 am

Quoting Klaus (Reply 25):
well-verified assembly code is more stable and more reliable than high-level code

We'll just have to agree to disagree on this point.

Quoting Klaus (Reply 25):
The kind of documentation I habitually add to the code describes primarily why the code is doing what it does at that point, in that function or in that module.

There's no reason why such a description should not be part of the code comments. In fact I would argue it should be.

Quoting Klaus (Reply 25):
If documentation merely tells you how the code is operating, it's basically redundant. And since that's the only purpose most programmers can think of, they simply don't do documentation.

What about assembler language? A flow chart is almost essential, yet only tells you what the code is doing.

Quoting Klaus (Reply 25):
The lack of conceptual documentation is highly dangerous

Which is why such concepts should be described in the code comments.

Quoting Klaus (Reply 25):
When you still have the option to switch to the next-larger CPU derivative in order to be able to use bulkier and slower code, things are a bit different.

I repeat, the constraints you list all apply. Nobody deliberately writes slow and bulky code, except Microsoft Big grin
 
Lemurs
Posts: 1320
Joined: Sat Mar 12, 2005 5:13 am

RE: Boeing/Airbus FMCs

Thu Oct 20, 2005 2:51 pm

Quoting Jetlagged (Reply 26):
I repeat, the constraints you list all apply. Nobody deliberately writes slow and bulky code, except Microsoft

The difference is, if Microsoft were writing the code, it would run on just about any system in the world, not just on one. People have no idea how heavily optimizied our code is because they all have their own individual complaints...if you sit down and try and write truly general purpose software, you'd find it more daunting than any real-time computing environment where you control every single component, input and output.

I know you were being intentionally obtuse, but I couldn't let that one go. Big grin
 
User avatar
Jetlagged
Posts: 2564
Joined: Sun Jan 23, 2005 3:00 pm

RE: Boeing/Airbus FMCs

Fri Oct 21, 2005 1:25 am

Quoting Lemurs (Reply 27):
I know you were being intentionally obtuse, but I couldn't let that one go

I knew it would upset someone! It was too hard to resist typing that. I am actually consistently amazed at the way it is all things to all people. However a lot of "features" seem to be there because it can be done, rather than because it ought to be. And then there are the infamous easter eggs. And Office Assistant  banghead  (I think I'll know when I'm trying to write a letter ....)
 
Klaus
Posts: 21761
Joined: Wed Jul 11, 2001 7:41 am

RE: Boeing/Airbus FMCs

Sun Oct 30, 2005 7:11 am

Quoting Jetlagged (Reply 26):
We'll just have to agree to disagree on this point.

No problem.  Smile

Quoting Jetlagged (Reply 26):
There's no reason why such a description should not be part of the code comments. In fact I would argue it should be.

That's exactly what I'm saying.

Quoting Jetlagged (Reply 26):
What about assembler language? A flow chart is almost essential, yet only tells you what the code is doing.

Yes, the need for proper conceptual documentation is even more pronounced for assembler than it is for high-level languages.

Quoting Jetlagged (Reply 26):
I repeat, the constraints you list all apply.

No, if the option exists to proceed to a larger controller the constraints don't apply to the same degree.

Quoting Jetlagged (Reply 26):
Nobody deliberately writes slow and bulky code, except Microsoft

I actually have the impression they do try... but for all their resources and manpower, it's completely baffling how they consistently fail to achieve anything.

Quoting Lemurs (Reply 27):
The difference is, if Microsoft were writing the code, it would run on just about any system in the world, not just on one.

That's got nothing to do with it.

Who is online

Users browsing this forum: kalvado and 10 guests

Popular Searches On Airliners.net

Top Photos of Last:   24 Hours  •  48 Hours  •  7 Days  •  30 Days  •  180 Days  •  365 Days  •  All Time

Military Aircraft Every type from fighters to helicopters from air forces around the globe

Classic Airliners Props and jets from the good old days

Flight Decks Views from inside the cockpit

Aircraft Cabins Passenger cabin shots showing seat arrangements as well as cargo aircraft interior

Cargo Aircraft Pictures of great freighter aircraft

Government Aircraft Aircraft flying government officials

Helicopters Our large helicopter section. Both military and civil versions

Blimps / Airships Everything from the Goodyear blimp to the Zeppelin

Night Photos Beautiful shots taken while the sun is below the horizon

Accidents Accident, incident and crash related photos

Air to Air Photos taken by airborne photographers of airborne aircraft

Special Paint Schemes Aircraft painted in beautiful and original liveries

Airport Overviews Airport overviews from the air or ground

Tails and Winglets Tail and Winglet closeups with beautiful airline logos