VMs allow for a higher level of error detection and automatic fail-over than traditional embedded systems. They also allow you to upgrade capability by simply adding or upgrading ICP cards. Instead of a few processors running complex groups of functions, you have many VMs running simple groups (or singular) functions. VMs lower cost by allowing for standardized processors instead of specialized processors.
As an example of the F-35’s software stability, not a single one of the 1800+ test flights was aborted due to a software issue.
Sens, you might want to do a little research on the F-35’s systems and how it deals with software error detection and fault tolerance before making such claims.
Here are a few presentations (with audio) to get you started.
(You have to advance the slides to follow the audio)
They require you to signup, but its free.
btw, the F-35 runs on segregated “virtual machines” to give you an idea of its fault tolerance.
If the F-35 software was not modular, then they would not be able to build and develop pieces of Blk3 before Blk 2 was done.
On the “Blue Screen” front, the F-35’s software is designed to process independently, ie if the EODAS part takes a dive, it does not affect the rest. The main display is even split in two parts so you can put a bullet in one side and functionality switched to the other. There is even a small central display below the main one that can give basic CNI functionality in case both main displays go down.
Even if the process that integrates the data goes down, the display can be reconfigured to show each sensor’s data and the F-35 can still prosecute the mission.
You are mistaken. The F-35 learned it’s lesson from the F-22 problem and segregates a lot of the processing of the sensor information. The processing of the sensors and the integration of the resulting data is handled separately. This is why you can have multiple testbeds flying with different hardware configurations all testing the same code (its modular).
If you ever have to go back to the beginning, it’s time to stop being a programmer π

They are basing the official estimates on the hobbled F135 numbers… unless you think LM and members of the Australian Defense department lied (under penalty of perjury) to the AU Parliament?
Those calculations are based on two things that will allow the F-35 to meet the original spec.
1. The SDD has a 5% fuel reserve that cannot be used in the calculation.
2. The F135 is being penalized in performance (5% fuel flow and 2% thrust). Plug in the actual performance of the F-35 and it has no problem meeting the spec.
Spud – You done gone lost me on that chart.
On TR-2 I see onboard S/W in the red and offboard not started.
You have me there, this chart threw me for a while until I started getting into software programmer mode. The thing to remember is that the software blocks (and sub blocks) are no linear. In other words, you can be working on Blk 3I before you have finished with Blk 2B.
The thing that allows this is the software’s modularity. For instance, the difference in progress from Blk2A and Blk2B is only the modules added to Blk2A that give it 2B functionality. Looking at the chart, you can see that Blk2B software is between 90% and 95%. Looking at the Blk3I software, it is at 30% (10% behind plan). To understand Blk3I, it is basically Blk2B adjusted for the new hardware of TR2 (no new features added). The Supplier SW for TR2 is at 67% (only 1% behind plan).
They are (or were) behind a bit on Blk3I, but I think they can make it up within the year. How so? In July of 2011 they were at 15% of 36% plan and three months later they were are 30% of 40% plan. Who knows, at that rate they could already be back on track.
Ground software will always lag behind the airborne stuff because it has to emulate/learn from flights in order to predict behavior correctly.
Here is the discussion the F-35s will surpass their specifications with the formidable F135 delivering more trust on the bench at least. π
Keep in mind that they are handicapping the performance of the F135 when calculating KPPs.
In recent AU Parlament Testimony:
Mr Burbage: We have 16 key performance parameters on this airplane. Half are logistics and sustainment-related, half are aeroperformance-related and one or two are in classified areas. We have an oversight body called the Joint Requirements Oversight Council, the JROC, that looks at those requirements every year and makes decisions on themβ’Are we going to meet them, are we not going to meet them? If we are not going to meet them, what is the impact of that?’ We have one this year which was the range of the Air Force airplane which had a specific set of ground rules associated with how that range is calculated which is not similar to either of the other two airplanes. The airplane flies a large part of its mission at a non-optimised altitude in the original calculation. The JROC agreed to change the ground rules to fly that airplane as the other two were flown and, when that happened, the airplane had excess margin to the range requirement. For any performance-related requirements, we artificially penalise the engine by five per cent fuel flow and two per cent thrust. Those margins are given back as we mature the design and get more and more solid on exactly what it is going to do. They are there for conservative estimation up front. We have not taken back any of those margins yet so, when those margins are taken back, the airplane will continue to be well in excess of its basic requirement. The airplane is meeting all of the other requirements today.
Senator FAWCETT: So have those requirements like schedule and cost been rebaselined, or are they are still the original ORD?
Mr Burbage: Schedule and cost are not KPPs. I thought you were talking about performance.
Senator FAWCETT: No, I recognise that. You have rebaselined schedule and cost as you have gone along. What I am asking is have the KPIs been rebaselined and does the statement you just made apply to today’s KPIs or does it also apply to the original ones?
Mr Burbage: To the original set. Today, all the KPPs are green because that ground rule was changed to be common across all three airplanes on the range. But we have not taken back the margins that are being withheld to make sure those performance predictions are conservative. We are not going to have degraded engines. We basically measure our performance characteristics with a highly-degraded engine capability. Our actual flight test information coming back from the engine is better than nominal. These calculations are not done using actual airplane test data. They are done using an artificial penalty that gets paid back as the design matures.
Hey Spudman:
The people that are going to look at this would be the equivalent of your GAO, independent bureaucrats that are not political appointees nor “unionized” in the way I think you mean. Like in the UK, Canadian parliamentary tradition places a lot of emphasis on smart senior public servants that are outside the political process and who outlast most politicians in their jobs doing a large part of actually running the day to day affairs of the state while the politicos focus on whatever the hell they focus on.
That being the case, then I welcome it.
The avionics hardware has been flying for years. TR2 (Tech Refresh 2) comes along with Blk2B next year and that is final hardware for IOC.
There is only tweaking if needed to be done.
Besides the hardware, 80% of the software is flying.
Here are the latest two software “snapshots” to show where they are now (Nov 2011) where they were last July. In case you missed it, TR2 supplier software is at 67% and Blk2B software is at >90%.
That sure sounds like “most” to me.
November 2011

Being American, I am not as up to date on the Canadian system as much as my brothers north of the border.
I was just thinking that if Canadian Public Servants (Unionized?) are anything like those here in California, you are in for a world of hurt, decades of delays, and end up with F-35s that are 3x more than they are today.
Great… public works guys in charge of a defense project, that will work out just fine π
Spud – Surely the slip in IOT&E completion reflects a slip in IOT&E start, which in turn reflects a slip in completion of DT? Or are you suggesting that the JSFPO and the Pentagon are imposing some random delay?
This mini-thread started when I said that the F-35’s avionics are mostly done, which they are. TR2 hardware has been flying for a while, 80% of the software is flying, and more than 80% of the software is written. I am not saying that 80% of the sotware is verified, far from it. A majority of the work left to do is verification, not creation of the software/hardware.
Boeing and EF were offering combat-ready aircraft in 2016, according to the requirement, but this was apparently waived for the JSF.
The first aircraft for Japan will be stateside trainers and will be Block3 (just not complete with the USAF’s IOT&E). If they wanted to they could takeoff and go into combat just fine.
When the plane enters IOT&E the SDD program is done. While there may be small tweaks here and there, development is done at that point.
Sens, you are correct that most of that is done, thanks to the large amount of concurrency that the F-35 program has. This is one of the reasons why it makes little sense that they would push IOC so far to the right after SDD has completed (by almost two years).
IOT&E is not about developing & testing the plane, but about developing the tactics & maintenance practices that the F-35 will use once it goes IOC.
Dedicated operational test and evaluation conducted on production, or production representative articles, to determine whether systems are operationally effective and suitable, and which supports the decision to proceed Beyond Low Rate Initial Production (BLRIP).