Ada holding up F-22 Raptor upgrades(defensenews.com)
defensenews.com
Ada holding up F-22 Raptor upgrades
http://www.defensenews.com/story.php?i=6559166&c=AME&s=AIR
37 comments
I have no idea about their overall code quality but there was a famous F-22 bug found a few years ago where it lost all navigation systems when crossing the international date line.
http://www.defenseindustrydaily.com/f22-squadron-shot-down-b...
http://www.defenseindustrydaily.com/f22-squadron-shot-down-b...
Date/Time code is notorious. It always seems simpler than it actually is. There are always corner cases you forgot about. None of it is rocket science. Instead, it's the stupid arbitrariness of it that gets you. (Commodity trading is often the same.)
My boss taught me that whenever the word date / time / etc creep into a spec double your estimation for completion.
He was trying to be funny to make a point... but there is definitely a nugget of truth to it. Time is hard. (I write embedded DVR software these days)
He was trying to be funny to make a point... but there is definitely a nugget of truth to it. Time is hard. (I write embedded DVR software these days)
Stealing a joke from a co-worker, I think that should be called an epoch fail.
But I want the lolly NOW!!!!
But seriously, Ada is well designed and not difficult. Ada is not part of the problem, this would take longer and be less reliable in C++.
But seriously, Ada is well designed and not difficult. Ada is not part of the problem, this would take longer and be less reliable in C++.
The article actually nails the real reason: the USAF bought far fewer F22s than it originally planned, so things like this that apply equally to 1 or 1000 have to have their cost spread over far fewer individual units. I'll bet that the F22 software is not actually that much more complicated than that controlling a modern car, yet Ford or whoever can spread the cost over a million units.
> I'll bet that the F22 software is not actually that much more complicated than that controlling a modern car, yet Ford or whoever can spread the cost over a million units.
I'll bet it is. A car is significantly simpler than a fighter plane (at all levels of resolution), even when you discount weapons and detection systems. Which you can't discount when you're building software for a plane.
Furthermore, the risks involved in a fly-by-wire avionics soft are much greater than in cars in case of bug or crash: there are no drive-by-wire production cars today, although there are many electronics systems.
I'll bet it is. A car is significantly simpler than a fighter plane (at all levels of resolution), even when you discount weapons and detection systems. Which you can't discount when you're building software for a plane.
Furthermore, the risks involved in a fly-by-wire avionics soft are much greater than in cars in case of bug or crash: there are no drive-by-wire production cars today, although there are many electronics systems.
It's true there are no end-to-end 100% drive-by-wire cars. But there are certain drive-by-wire systems in many modern cars. Electronic throttle control[1] is widespread (or universal?) and brake-by-wire[2] is already used by Mercedes and Toyota.
1. http://en.wikipedia.org/wiki/Electronic_throttle_control 2. http://en.wikipedia.org/wiki/Brake-by-wire
1. http://en.wikipedia.org/wiki/Electronic_throttle_control 2. http://en.wikipedia.org/wiki/Brake-by-wire
Electric steering, too
http://en.wikipedia.org/wiki/Power_steering#Electric_systems
Several years ago, a friend bought a BMW M6 the year they came out. A few days later, he noticed when the tires were pointed straight forward, the steering wheel was not centered. He took it to the shop, and they told them "that's a software bug".
http://en.wikipedia.org/wiki/Power_steering#Electric_systems
Several years ago, a friend bought a BMW M6 the year they came out. A few days later, he noticed when the tires were pointed straight forward, the steering wheel was not centered. He took it to the shop, and they told them "that's a software bug".
We've had self-landing planes and autopilots for a long time. Self-driving cars are still a long way off. So I would say that don't underestimate what software you need in a car.
And even if the F22 is 10x as complex, Ford still has 100,000 cars to spread the cost across.
And even if the F22 is 10x as complex, Ford still has 100,000 cars to spread the cost across.
That's the result of a combination of two things: aircraft don't often have one of the major problems that cars have (dense traffic and other obstacles), and that the problem of dissimilar surfaces was solved, for aircraft, by making the surfaces more similar. Cars instead have to be able to negotiate a variety of terrain.
So, safely automating cars is a harder problem, but not because the car itself is a more complex vehicle.
So, safely automating cars is a harder problem, but not because the car itself is a more complex vehicle.
A harder problem requires more complex software, no? The complexity of the vehicle itself is actually not a factor.
Oh, you're right. Somehow I misread your earlier statement as being about the complexity of the machines themselves.
I agree totally with you then. Even accounting for avionics, control surfaces, target acquisition, and so on and so forth, automating cars is a much harder nut to crack, software-wise.
I agree totally with you then. Even accounting for avionics, control surfaces, target acquisition, and so on and so forth, automating cars is a much harder nut to crack, software-wise.
Fly-by-wire avionics go beyond "just" self-landing and auto-pilot (and these are no small accomplishments!). In fly-by-wire aircraft, when the flight controls are moved, it's the software that calculates how to move the control surfaces to achieve the desired result. Also, modern fighters are often designed to be inherently unstable, to achieve greater maneuverability. So even in level flight, the software must calculate and order constant tiny movements to maintain stability. These movements happen dozens to hundreds of times a second, and must take into account factors such as current speed, attitude, air flow across the aircraft, etc.
OK, everyone here who codes in ADA, raise your hand. Atlas?
I hadn't known much about Ada other than that it's very old (as programming languages go) and it has a kind of nonspecific bad reputation, but I looked it up on Wikipedia and it actually doesn't look like an unpleasant language at all from the article. I particularly like its built-in message-passing system for concurrency: http://en.wikipedia.org/wiki/Ada_(programming_language)#Conc...
On projects like this I would worry more about accumulated technical debt from decades of modification than the language they're written in. (I suppose the language can complicate the task of hiring programmers who are skilled with its idiosyncrasies, but that's hardly an insurmountable or crippling problem.)
On projects like this I would worry more about accumulated technical debt from decades of modification than the language they're written in. (I suppose the language can complicate the task of hiring programmers who are skilled with its idiosyncrasies, but that's hardly an insurmountable or crippling problem.)
From my defense software experience with Ada 83 and Ada 95, Ada's concurrency features made it much easier to work with than C. Tasks/processes were a top-level feature of the language, like classes in Java, and the "protected" keyword functioned somewhat like "synchronized" in Java (an implementation of the monitor pattern).
Our compiler package also came with an extensive concurrency API that offered a variety of threadsafe containers comparable (again) to java.concurrent - and this was software from the late 80s/early 90s!
What was bad about Ada was Ada 95. It strove to make Ada into an object-oriented language, but did a poor job of it with some very tortured syntax. edit what Masklinn said - "bolted on" is a perfect way to put it.
Our compiler package also came with an extensive concurrency API that offered a variety of threadsafe containers comparable (again) to java.concurrent - and this was software from the late 80s/early 90s!
What was bad about Ada was Ada 95. It strove to make Ada into an object-oriented language, but did a poor job of it with some very tortured syntax. edit what Masklinn said - "bolted on" is a perfect way to put it.
There are many nice ideas in Ada, but I have two big issues with it:
1. It's a very lawyery language, there are very few things the compiler will accept to infer, which makes Ada tedious to read and write.
2. The strange mix of underscores and uppercases that is the normal Ada writing style (I believe Ada identifiers are case-insensitive, code from the 80s tends to be VERY_UPPERCASE_HEAVY while the same code now Tends_To_Be_Strangely_Capitalized) makes my head hurt.
And since this is avionics, they're probably dealing with embedded code (which tends to be even less readable) as well...
And as totalc notes, the OO additions of Ada 95 (if you have access to them) feel very bolted on and unnatural.
1. It's a very lawyery language, there are very few things the compiler will accept to infer, which makes Ada tedious to read and write.
2. The strange mix of underscores and uppercases that is the normal Ada writing style (I believe Ada identifiers are case-insensitive, code from the 80s tends to be VERY_UPPERCASE_HEAVY while the same code now Tends_To_Be_Strangely_Capitalized) makes my head hurt.
And since this is avionics, they're probably dealing with embedded code (which tends to be even less readable) as well...
And as totalc notes, the OO additions of Ada 95 (if you have access to them) feel very bolted on and unnatural.
I was taught Ada95 by John McCormick, who wrote several textbooks on Ada.
Though I can't claim any professional experience, lots of my college education was straight from DoD/Navy expats who wrote military software.
There are lots of firms in the midwest that write this kind of software. John Deere, Lockheed, etc.
Though I can't claim any professional experience, lots of my college education was straight from DoD/Navy expats who wrote military software.
There are lots of firms in the midwest that write this kind of software. John Deere, Lockheed, etc.
I write real-time avionics software for my day job. It's done almost entierly in Ada95.....I don't work on the F-22's.
So then what's your take on coding in Ada compared to other languages?
I've played with it, it's a nice language. Don't see why people hate on it, it's not especially verbose, and the static types are actually helpful (like, you can cleanly loop over the extent of an enumerated type, for example) as well as more than usually protective (like, you can type define "inches" and "centimeters" as kinds of integer, and it won't let you mix them by accident).
F# has units of measure too.
It goes a bit deeper than that.
Most static typed languages - C, Java, Haskell, etc are memory representation centric in their primitive types. Ada is usage centric.
You see that two ways.
First, in most languages any item with underlying implementation X can represent any legal value of X, even if it makes no sense. If you want to represent a quantity whose maximum value is one million, putting it in anything shaped like a 32-bit int will let it contain the illegal value "one million and one". Contrast Ada which will let you cap its legal range.
Second, in most languages any item with underlying implementation X can contain anything else with the same implementation. Your typedef'd int can be put into anything else int-sized. Contrast Ada, which won't permit you to mix apples and oranges if they are defined as distinct types with int storage.
Most static typed languages - C, Java, Haskell, etc are memory representation centric in their primitive types. Ada is usage centric.
You see that two ways.
First, in most languages any item with underlying implementation X can represent any legal value of X, even if it makes no sense. If you want to represent a quantity whose maximum value is one million, putting it in anything shaped like a 32-bit int will let it contain the illegal value "one million and one". Contrast Ada which will let you cap its legal range.
Second, in most languages any item with underlying implementation X can contain anything else with the same implementation. Your typedef'd int can be put into anything else int-sized. Contrast Ada, which won't permit you to mix apples and oranges if they are defined as distinct types with int storage.
We had a project in our "Programming Languages" class that consisted of solving a problem in a number of different languages, including Ada, which proved to be the most difficult simply because of the lack of decent resources or guides online. I'm not saying I couldn't get accustomed to it, but with just about any other language you can go online and find a few guides that'll get you acquainted with the paradigm of a language, and I couldn't find anything like that for Ada. Programming in Prolog was easier because at least then I could go to our library and dust off a book from the late '80s about how to write programs in Prolog.
when I went to Uni, the main language we used was Turbo Pascal (followed by loads of assembly and a small amount of C). The year behind us had Turbo Pascal replaced by Ada as that was going to be the Next Big Thing.
The Ada class started in '94 if a timeframe helps
The Ada class started in '94 if a timeframe helps
Does VHDL count?
Me!
Well not really, but Ada is alive and well in the guise of PL/SQL. You can see it if you look closely, type "desc sys.diana" into any Oracle DB, DIANA is "descriptive intermediate annotated notation for Ada".
Well not really, but Ada is alive and well in the guise of PL/SQL. You can see it if you look closely, type "desc sys.diana" into any Oracle DB, DIANA is "descriptive intermediate annotated notation for Ada".
What's used in place of Ada nowadays?
The Joint Strike Fighter software is written in C++. Meanwhile, the EuroFighter project is still using Ada.
C and C++. Ada is used less for new projects, but existing projects aren't switched over - many projects have long lifespans going over a decade or more.
OCaml would be a great fit for this space, so would Haskell or Scala...
Oh hellz no! Most of the systems ADA is used for tend to be realtime stuff. The moment you utter the words "Garbage Collection" you throw your realtime guarantees down the toilet.
Tell that to Airbus: http://www.astree.ens.fr/
Hardly the same thing though. Astrée is a static analyzer used to help prove avionics code written in C, it's not used in any onboard avionics systems. So its lack of real-time processing is not important.
If you're writing real-time avionics software, your choices are really only Ada, C and C++. Most companies I know of, including Airbus, are using C. Typically, avionics software has to be qualified to DO-178B/ED-12B standards which specifies certain development, testing and proofing requirements. Software verification tools like Astrée are also governed by DO-178B/ED-12B, though they are subject to a lighter verification process.
If you're writing real-time avionics software, your choices are really only Ada, C and C++. Most companies I know of, including Airbus, are using C. Typically, avionics software has to be qualified to DO-178B/ED-12B standards which specifies certain development, testing and proofing requirements. Software verification tools like Astrée are also governed by DO-178B/ED-12B, though they are subject to a lighter verification process.
C++
Now I'm not in this industry, but I know that planes these days are extremely complicated beasts and require a ton of code to run everything properly. I worry that if development is artificially sped up, that code problems that would have been caught in the testing get caught in production.
Of course the above kind of assumes a decent dev team and a good code base. What I said could be moot if what's really happening is the technical debt of some of this code is so massive that simple changes take months to make and ensure correct, which would be a problem for sure.
Either way, blaming the language probably isn't the right way to go about this.