Lockheed Martin F-35 Lightning II Joint Strike Fighter (JSF)

Colonial-Marine said:
I can only assume LM has scooped up huge numbers of coders in recent years, yet I'm still left asking what the hell the problem is? For all of the things Lockheed gets right, they seem particularly bad when it comes to the software side of things. The F-22 also had its own long list of problems there, and difficulties with integration of updated hardware, but the whole point of the tech refreshes and such was based on that experience. So where is the weak link in the chain here?
Click to expand...
If I had to name one link, it's that doing A2A with stealth is really difficult and requires real-time machine fusion of your radar with passive sensors and offboard data. In the 80s (F-22 architecture) that was considered supercomputer power and you could only fit one such computer on the airplane, so it did everything, including FCS and VMS. In 1994 there was no other way to do it so F-35 is the same.

Trouble is, it's not only complex (in the sense of lots of things interacting with each other and with the outside environment) but because it gets into FCS/VMS it's flight-critical. So whenever you change anything you have to do regression testing to make sure haven't gooned up something important that worked before. Like when you plugged a scanner into your computer and the printer stopped working.

With more computer power in less space, you could do it differently, with more processing at the sensor, and Saab were the first to borrow the idea of partitioning the mission functions from FCS, which was part of Gripen NG from the outset (2007). That's how it's done on the B-21 (and, I believe, Rafale F4). But with F-22 and F-35, the upgrades are slow and painful.
 
LowObservable said:
With more computer power in less space, you could do it differently, with more processing at the sensor, and Saab were the first to borrow the idea of partitioning the mission functions from FCS, which was part of Gripen NG from the outset (2007).
Click to expand...
Do you mean to say that a more strongly partitioned, more federated system with a fast and deterministic data transfer (databus) system might be more stable and more tolerant to subsystem changes? Heathen! Blasphemer! Say the VMEBus salesman!

I thought that some learned from the lesson of FIRAMS cowering in a corner of the F/A-18A YUK-14 memory space. (i.e. "we can't fix FIRAMS because that *might* boodle up the MC Exec software!)
 
It's also worth bearing in mind that the integrated triplex computing approach is also lower mass than a federated approach (for similar technology level), and that every little bit helps for STOVL. As well as the Px cards you've also got the boxes, racks, data cables, power cables, cooling etc. It's not all negatives from an integrated approach.

When we look at software upgrades being slow and painful, it's worth bearing in mind that we have no idea from the outside how much functionality is being added or changed, and what volume of code (SLOC as a poor but roughly correct measure) this translates to. This makes good comparisons between different aircraft and programmes very difficult.
 
aim9xray said:
I thought that some learned from the lesson of FIRAMS cowering in a corner of the F/A-18A YUK-14 memory space. (i.e. "we can't fix FIRAMS because that *might* boodle up the MC Exec software!)
Click to expand...

What was that all about and is there anything about it on the wikipedia?

Edit: Is the YUK-14 a reference to the AN/AYK-14?
 
Last edited:
Colonial-Marine said:
I can only assume LM has scooped up huge numbers of coders in recent years, yet I'm still left asking what the hell the problem is? For all of the things Lockheed gets right, they seem particularly bad when it comes to the software side of things.
Click to expand...

It's not just hiring them...its retaining them. I suspect that LM is not able to compete financially with the tech sector for the best of the best either....or even the average...

It's not that well known....but BAE Systems at Samlesbury in the UK have been drafted in to assist the F-35 software, they have a lot of Dev's there now working on it...I know someone who use to head up a team there, he was sent to Germany to do similar at Manching....and has in the past been over to help LM get well on a programme, in of all places Skunk Works....he wouldn't tell me much at all, and in truth his visibility of things there was limited (they were very compartmentalised, no glimpses of anything in hangars that isn't known) but he came away distinctly unimpressed...he thought their processes and standards were shambolic in his field....
 
timmymagic said:
It's not just hiring them...its retaining them. I suspect that LM is not able to compete financially with the tech sector for the best of the best either....or even the average...

It's not that well known....but BAE Systems at Samlesbury in the UK have been drafted in to assist the F-35 software, they have a lot of Dev's there now working on it...I know someone who use to head up a team there, he was sent to Germany to do similar at Manching....and has in the past been over to help LM get well on a programme, in of all places Skunk Works....he wouldn't tell me much at all, and in truth his visibility of things there was limited (they were very compartmentalised, no glimpses of anything in hangars that isn't known) but he came away distinctly unimpressed...he thought their processes and standards were shambolic in his field....
Click to expand...

I would guess it's the other way around: LM devoid a lot of time recruiting Software engineers that are unable to match the Sciences that is needed in Aerospace.
The fashion codding industry is not providing individuals with a strong academic background a favorable environment to grow a career that would help them to have all the headers to attract HR filtered eyes.

The IA frenzy would bring even worst results.
 
Basically, both approaches were based around the idea that such things as software documentation were unnecessary. With predictable results.
 
Actually the idea is to get something useful, even small bits, to the customer - as fast as possible. With rapid feedback to improve on what's delivered. In practice, some of the useful stuff cannot be divided into useful components small enough for rapid delivery.
Skimping on documentation happens in traditional 'waterfall' development as well, with dire results.
Properly managed agile software development will produce proper documentation, even if wooden mallets are needed for encouragement.
 
LowObservable said:
If I had to name one link, it's that doing A2A with stealth is really difficult and requires real-time machine fusion of your radar with passive sensors and offboard data. In the 80s (F-22 architecture) that was considered supercomputer power and you could only fit one such computer on the airplane, so it did everything, including FCS and VMS. In 1994 there was no other way to do it so F-35 is the same.

Trouble is, it's not only complex (in the sense of lots of things interacting with each other and with the outside environment) but because it gets into FCS/VMS it's flight-critical. So whenever you change anything you have to do regression testing to make sure haven't gooned up something important that worked before. Like when you plugged a scanner into your computer and the printer stopped working.

With more computer power in less space, you could do it differently, with more processing at the sensor, and Saab were the first to borrow the idea of partitioning the mission functions from FCS, which was part of Gripen NG from the outset (2007). That's how it's done on the B-21 (and, I believe, Rafale F4). But with F-22 and F-35, the upgrades are slow and painful.
Click to expand...
On the F-22 the flight critical systems like the triplex FLCS are separate from the two CIP mission computers (supercomputers back in the 1990s), and are connected on a 1553 bus to the VMS and IVSC while the mission avionics use high speed data bus and fiber. That said, the integrated avionics architecture of the mission systems did make upgrades very difficult, although since 2021 the CIPs were upgraded with open systems architecture modules and software capability releases moved away from the waterfall method to Agile software development (DevSecOps) with annual releases.

That said, Agile software development isn’t a cure for everything and you still need proper documentation to prevent headaches later on. And frankly not everything in software needs to be Agile either.

I’m not sure if the F-35 ICP handles flight-critical functions, but issues with regression testing has certainly been enough for the DOD to halt deliveries. I recall reading a Naval Postgraduate School paper that describes the incorporation of Agile into the F-22 and F-35 software development pipeline, and apparently the former is having more success than the latter.
 
Last edited:
Arjen said:
Actually the idea is to get something useful, even small bits, to the customer - as fast as possible. With rapid feedback to improve on what's delivered. In practice, some of the useful stuff cannot be divided into useful components small enough for rapid delivery.
Skimping on documentation happens in traditional 'waterfall' development as well, with dire results.
Properly managed agile software development will produce proper documentation, even if wooden mallets are needed for encouragement.
Click to expand...

The fun really starts when someone, newly versed in management speak after going on a course, asks if you can 'do Agile' in an infrastructure programme...
 
timmymagic said:
I suspect that LM is not able to compete financially with the tech sector for the best of the best either....or even the average...
Click to expand...
Not to mention finding coders who are willing to put up with random drug tests and polygraphs, or to work on technology that is obsolete in the non-defense field.
aim9xray said:
Do you mean to say that a more strongly partitioned, more federated system with a fast and deterministic data transfer (databus) system might be more stable and more tolerant to subsystem changes?
Click to expand...
Burn me, see if I care.
 
Last edited:
Sunday thoughts...
Can the F-35 A/C carry the GBU-31 JDAM with the MK-84 warhead internally?
The reason I'm asking is that GBU-31/MK-84 is 18" diameter, whereas GBU-31/BLU-109 is only 14.5".
Edit: The former is also longer: 152.72" vs 148.6".
 
Last edited:
Pax River Museum also has the original X35-C, which was for basic flight characteristics tests and used some "spare parts" from other aircraft in the initial test flight program. The placard below lists the various parts and differences from the first operational test model F-35C CF-01. They also have the losing X-32B (with the large ventral intake, earning it the nickname of "The sailor inhaler").
 

Attachments

  • IMG_1130.jpeg
    IMG_1130.jpeg
    1.7 MB · Views: 19
  • IMG_1142.jpeg
    IMG_1142.jpeg
    1.1 MB · Views: 19
  • DSCN0132.jpeg
    DSCN0132.jpeg
    1.6 MB · Views: 16
  • DSCN0137.jpeg
    DSCN0137.jpeg
    1.4 MB · Views: 18
  • DSCN0135.jpeg
    DSCN0135.jpeg
    1.3 MB · Views: 19

Similar threads

Back
Top Bottom