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: 21
  • IMG_1142.jpeg
    IMG_1142.jpeg
    1.1 MB · Views: 21
  • DSCN0132.jpeg
    DSCN0132.jpeg
    1.6 MB · Views: 17
  • DSCN0137.jpeg
    DSCN0137.jpeg
    1.4 MB · Views: 19
  • DSCN0135.jpeg
    DSCN0135.jpeg
    1.3 MB · Views: 20
Colonial-Marine said:
I find this an interesting question to consider. The Navy's F/A-18 was originally intended to come in two variants. The A-18 would replace the remaining A-4s and A-7s, while the F-18 would replace remaining F-4s and supplement the F-14. Improvements in computing meant one variant could carry all of the avionics necessary to both roles. But from my understanding prior to this time there had been a distinct separation between the attack and fighter pilot "community". So how much would the ability to perform the attack mission have suffered from the merger of the two? Pilots who would formerly be specialized in ground attack would now be expected to be equally adept in air-to-air combat and that requires a lot of training that isn't relevant to dropping bombs. Did the same thing occur when the A-6 Intruder was finally retired and their role taken over by the Super Hornet?

The Air Force never had that same love of specialized attack aircraft, instead preferring fighter-bombers that were more oriented to strike/interdiction missions. Despite this the A-10 and to some extent the A-7 still meant a community of pilots for those aircraft who would primarily be focused on the task of close air support. Advances in precision guided weapons and sensors have changed many things but I'm sure there is still a great use for pilots well experienced in working with FACs and other elements on the ground in direct contact with the enemy. Even if there is no dedicated successor to the A-10 I think it might make sense to have some squadrons who are more concentrated on what we'd consider "attack" missions despite flying a multi-role fighter like the F-35.
Click to expand...
That's probably how it should work, not sure the USAF is doing that.

I know I'd want F35 drivers spending time practicing for interdiction and strike missions in preference to A2A.


Jeb said:
I've never bought into the idea that just because an A-10 driver transitions to an F-16 or Strike Eagle or F-35, that suddenly the pilot forgets how to work with JTAC and drop bombs and doesn't care about troops on the ground anymore.
Click to expand...
The pilot gets less practice time dropping bombs. Most of their time flying once they go to a new platform is going to be getting competent in the Air-to-Air fighting that they don't have much practice in, and then once they're competent they can afford to relax a little on the A2A side and drop more bombs. If they can get range time for that...
 

Similar threads

Back
Top Bottom