Saab markets Gripen E as the smart fighter. What makes it smart? Its designs? Its sensors? Its engine? Its mission system software? It’s a combination of all those factors, but mission system software is quite possibly the standout leader of the pack. Since the first days of the Gripen programme all variants operate with mission system blocks designated in the material system or MS-series. MS20 is the current standard used by all Gripen C and Gripen D aircraft in the worldwide fleet. MS21, the follow-on release, will be the first release used to equip production standard Gripen E and Gripen F fighters, those destined for the Svenska Flygvapnet and the Força Aerea Brasileira (the Swedish and Brazilian Air Forces).
However, Saab is using a series of M-series incremental mission system software releases for the Gripen E development programme.
These are overall programme designations that include support systems and are purely internal to the company, and will not migrate to customer production standard aircraft.
Saab’s Linköping-based Flight Test Unit has four dedicated Gripen test aircraft assigned to the ongoing flight test programme: Gripen D 39-7 and Gripen Es 39-8, 39-9 and 39-10. Each aircraft is configured with test-specific M-series mission system software and cockpit configurations.
Aircraft 39-7, a two-seat Gripen D, was successfully used as Saab’s Gripen NG demonstrator, and today is a testbed used to support the Gripen E programme with its aft cockpit configured with M1.3 standard software.
Aircraft 39-8, the first Gripen E prototype, is a flight sciences test aircraft configured with M1.3 standard software.
Aircraft 39-9 and 39-10, the second and third prototypes, are mission systems test aircraft configured with M1.4 standard software.
Johan Segertoft, project manager for M-series mission system software, said M1.4 is the basis for Saab’s internal rapid tactical development, in conjunction with the avionics system to enable a quick upgrade process. He said: “Aircraft 39-9 and 39-10 were built with all the systems necessary such that we can upgrade software continuously while doing flight testing. With M1.4, we made the central infrastructure functions of the aircraft data-driven functions that integration of new sensors and weapons require, like monitoring, central test recording and power management, which means we can conduct distributed development more easily.
“Developing M1.3 without data-driven functions saved us time, but also secured the overall functionality. We changed to data-driven functions in step two as a way of reducing risk. We also updated three of the computers – flight management, general electronics and the safety-critical part of the tactical management computer – to enable use of better processors.
“Changing the flight management computer took less than a week in terms of the effort required for our engineers. We changed the hardware in the rigs, booted up the system and it was working the same way it did before. Our measurements showed we had more CPU available.”
The tactical management computer is a multicore computer designed to provide a lot of power. It can be likened to a huge calculation cluster in the aircraft, housing two processors each designed to run safety-critical software. Greater computer power is required to run the all-important decision support and sensor fusion function for the Leonardo Raven ES-05 active electronically scanned array radar, the Leonardo SkyWard G infrared search and track sensor, and a Gripen-specific version of Saab’s Arexis electronic warfare system dubbed MFS-EW. Initially, Segertoft’s team ran testing on laboratory benches with a prototype algorithm run on multiple desktop computers to provide the amount of power required for the decision support and sensor fusion function. This successfully proved functionality such that the team then moved to a rig to test the algorithm in the multicore cluster. Once again it worked, which meant the team now had more power in the aircraft’s computer than the multiple desktop machines had provided in the lab.
Proving functionality of the decision support and sensor fusion function for the Gripen E is critical. Why? To support the aircraft’s suite of sensors, each operating at its optimum performance to enable the tactical management computer to fuse sensor data and present it on a common display without pilot interaction.
Engineers tried to merge the filtered information as presented to the pilot, who can oversee and interact with the fused display, select and deselect different levels, but this requires a huge amount of power. In order to fuse data, the fusion engine needs to be fed all data; otherwise the process is impossible.
Typically, in a real-time system, fusion can generate a lot of software errors, so the architecture used needs to decouple in a way that contains the errors so that focus can be applied to the fusion function.
Explaining the problem, Johan Segertoft said: “It’s tricky, because we don’t really know what type of algorithms will be available in five or ten years. Nor do we know how much power they will need or whether it will be available. This was a key challenge when we started roughly eight years ago. Hardware needs to be able to change, and we need to be able to upgrade software without causing a lot of problems. It was fun to see the prototype algorithms just dumping in on this platform and work; we expected them to, but you never know with software.”
As part of the build-up, Segertoft’s team undertook basic integration testing for the entire sensor package with all of the hardware available to allow them to focus on the software. At this stage the hardware included the on board oxygen generating system, the anti-g system, the EBRAG system, a redundant INS/GPS, the new ARC-210 radio, and a complete IFF system.
Johan Segertoft said: “The timeline was quite fast. We flew 39-8 on June 15, 2017, and first booted up M1.4 in the rigs on September 7, 2017, fitted all the hardware and completed a test readiness review to check we had the features and functions required, and the necessary documentation. For example, at power on, you need to prove it’s safe for the mechanics who work around the aircraft.
We powered on in March 2018, and formal system verification started in May. We handed aircraft 39-9 over to the Flight Test Unit in July 2018, added further functions to the tactical software with a much shorter formalisation period, and flew the aircraft for the first time on November 26.
“One key takeaway: we have radically reduced the number of software faults.
Operating with M1.4, we very rarely talk about software issues. When a software problem arises, the average turnaround time to fix a problem is within the same day. Because our engineers can quickly pinpoint where the problem is and because the whole architecture is automatically driven, all we have to do is write the new code to correct and it’s done.”
Discussing the verification process, Johan said: “We have an elaborate system for software testing with different levels of test that are automated not only for a specific feature, but also for the platform itself. We talk about the platform all the time, but it’s actually a system of tools, automated tests, configuration entities and code, which is why it took so long to develop. When you type in build, it will start to generate, automatically test and automatically tell you if you’re on the right track, but that is just to verify it’s working as intended to the specification.
The rigs are there to verify the specification is probably correct, because pilots need to be accustomed to the system and how it’s working. Test pilots provide feedback on any specification changes as they see fit as part of the constant loop used in verification.”
When running the software to test sensor fusion, the test team is dependent on two systems working together: the avionics computer system (ACS), which contains the sensors, and the avionics core computer system (ACCS), which contains various computers. From a user perspective, this looks like one logical computer. When running simulations in the rigs, the team uses different rig instalments that include different parts of the ACS and different parts of the ACCS.
Explaining the important part, Johan said: “We don’t want to limit what the radar feeds into the system, because that would put a limit for further development. Typically, we ask each system supplier to provide the full capability of their system. We use software to translate what’s supplied into what we are interested in. In the future, if a supplier wants to provide more capability, we change the software, which should take a day. We never try to limit and try to get everything in, which also makes us more decoupled from the evolution of the sensor itself.”
Saab’s objective for M1.4 was to integrate all the sensors and systems in the first round and not to limit the interface. Fortunately, Saab achieved the objective, and gathered plenty of data to develop further the data fusion capability and the speed at which it functions. Johan confirmed his team has already funnelled data from the radar, IRST and the IFF into the system, and has also started to fuse that data.
Equipped with this architecture, Segertoft’s team expects future upgrades to be much easier to complete and integrate. Because of the separation and set-up, operators, too, should be able to upgrade software, hardware and sensors thanks to the datadriven central functions.
Johan made an interesting comparison between the consumer software and defence industries, noting that by the early 2000s, consumer was outpacing every other market sector not least defence to a point that it’s no longer acceptable for the defence industry to take so long.
He said: “It’s easy to say that a system is upgradable. Everything is upgradable. Everything is adaptable. The key questions are, how fast can it be done, at what cost and who should be able to do it?”
Providing a pilot’s perspective, Mikael Olssen, head of Saab’s Flight Test Unit, said: “Today, what we see in the rig and what we then see in the Gripen E aircraft is more or less exactly the same. I can count the number of minor software glitches on one hand. This is not just stable, it’s super stable. Our test pilots have a level of trust [in the aircraft’s central functions] that they can advance the flight test programme quicker. If you can build in this trust so early, then as a customer with operational aircraft, you will have reliance on the software. It’s a game-changer.”
Johan gave one notable example that involved changing the flight management computers on aircraft 39-9 and 39-10 in less than a week: “Traditionally, integrating a new computer and getting it up and running smoothly could take up to a year, this time it was a smooth process. We wouldn’t have completed M1.4 in the time we did, without it.”
Mikael Olssen reckons the team has yet to grasp the full potential unlocked by the system and how it will change what Saab could potentially do: “That’s because we don’t fully understand how customers are going to apply those lessons and we need to explore how far the potential can take us.”
Given it currently takes three years to release a full package of MS software, how much time could be saved using the new process?
Answering, Johan described the method as a solution for changing the traditional way of upgrading software: “Liken your computer to a Gripen fighter loaded with software. There’s a lot of different boxes. Let’s say you want your computer to correlate GPS time with the datalink. Using the traditional process, changing the software would create the need to re-verify everything. Typically, that would take two years. Using the new system, the feature that fuses GPS time with the datalink is a particular software item. You change that software item. Using an example from aircraft 39-8 we corrected one line of code in safety critical software, which took roughly a week.”
Johan said the architecture used on Gripen E is not open architecture, but one based on aviation standards developed to meet the need to make changes faster. Explaining he said: “We have a hardware layer, a software layer and a platform layer in between. Hardware can be multiple computers. The platform layer will operate on all those computers, but the platform layer contains the software layers of individual components known as partitions. Tools operate on the platform code to arrange everything the way we want before it’s deployed to the computer.
Previously, developers wrote code for a feature and had to know where it would be placed on the operating system otherwise the operating system would place limitations on the feature. With this system, the platform layer provides the code with an application programme interface for orchestration of the feature’s functions.”
Johan reckons the M1.4 release is testament that the team is right and on the right track with its development: “We have more confidence and our plans look good. It’s much faster than the time required for a traditional plan to be executed.”
M1.4’s follow-on is M1.6, which is set to be the configuration loaded on aircraft 396001, the first production standard aircraft. M1.8 is already being planned, which is the configuration to be known as MS21 and targeted for series production Gripen Es.
