Why Saab delayed the first flight of the Gripen E

The first flight of the Gripen E – the latest variant of the Swedish fighter – was delayed by manufacturer Saab from the end of last year to the end of the second quarter of this year.

One of the major reasons the defense and aviation company is taking its time is its insistence on making sure the software installed on the single-engine Gripen E meets civilian standards.

Civilian Software Standards

These standards are a set of best practices that apply to software on civilian aircraft and are published by the Radio Technical Commission for Aeronautics (RTCA) in a document called DO-178C.

“We are applying civilian standards – so there is a standard for software called RTCA DO-178C and the C level is a very tough requirement. And the reason for us going to the C level is that we know that software is always a critical area and by going for this highest standard, we will have a very high level of quality and reduction of risk in the software,” says Carl Henrik Arvidsson, Head of Communications at Saab Aeronautics.

No Customer Requirement

Saab is proceeding with the implementation of these standards even in the absence of a customer requirement.

“It’s not a customer requirement. The customer requirement is to a lower level but this will bring us a lot of benefits and we will also achieve savings when we do upgrades in future by getting a much higher level of maturity in our complete system. In doing all this, we’re also setting a new standard,” explains Arvidsson, adding, “This is the system which will be in service for decades beyond 2050 and there will be new operational requirements from the customer. New technologies and new computers will become available, so going through this step will make it much easier to make sure that we can upgrade a Gripen according to either new technologies or to new customer demands in a cost efficient way.”

Reliable software is crucial to aviation today. The crash of an Airbus A400M at Seville, Spain on its first flight almost two years back was blamed on the incorrect installation of engine control software, which led to the failure of three of the four engines on the aircraft.

“We know that software often causes problems because so much is software driven today and for us it’s important to then have a high degree of control of the software. This is a way to prevent mistakes in the software. We do everything we can to avoid flaws in the software and that is why we’re working to this international standard, which stipulates very clearly how the process is done when we do the coding, when we verify the coding and when we prove the verification of the coding,” says Arvidsson.

The Gripen will be in operation beyond 2050 and right now it’s only the beginning of the program. There is a cost, but in the long run this is a small effort to gain a lot in the future. – Arvidsson

First Flight Postponed

Saab believes the time is well spent, considering the benefits that will accrue. The company had originally planned to go ahead with flight tests without complete software verification before the first flight. “Then we decided to postpone the first flight because we saw that the systems worked very well and we also saw the real benefit of taking this step before the first flight. The first flight is now scheduled or planned to happen before July and it (software verification) will be very close to 100 percent,” says Arvidsson.

The standards laid out by DO-178C are a catch-all for neat and clean coding that envisages multiple levels of verification of software. Compliance with the objectives of DO-178C is the primary means of obtaining approval of software used in civil aviation, except for experimental aircraft.

While it is widely considered impossible to develop software that is completely free of bugs, software under development is required to comply with the best practices and standards laid out by DO-178C to minimize the possibility of any failure of systems in flight, given that software can be coded in different ways to achieve the same objective, but different iterations could end up behaving in unpredictable ways.

DO-178C is the latest iteration of a set of standards for software that controls aircraft operations. The software on the Airbus A400M military transport, for example, adheres to the DO-178B standard, the predecessor to DO-178C.

According to Vance Hilderman, Chief Technology Officer of AFuzion Inc, an avionics certification services company, “DO-178C defines a set of up to 71 objectives which cover the full lifecycle of avionics software development and are based upon that software’s contribution to system safety.”

[stextbox id=”stratpost” caption=”DO-178C Explained”]

Hilderman has written papers on the DO-178C in which he says, “DO-178 is a relatively small document: vastly smaller than the documents you’ll produce to prove you followed it. It’s been said that the documents used to develop an aircraft would never fit inside that aircraft. Likewise, it’s guaranteed that the documents developed to comply with DO-178 exceed the page count of the printed source code. Why? Because like any regulatory framework for safety critical software, there are plans, standards, specifications, designs, reviews, analysis, tests, and audits necessary to define, evaluate, and prove conformance. The same is true for military aviation, medical devices, nuclear power, railroads, and safety-critical automotive software.”

According to Hilderman, “The ultimate goal, or measure of the ability to predict software’s reliability would be to answer the following question in the affirmative: ‘Can I prove this software is perfect?’ Invariably, for all but the more simple software programs, the answer is, ‘No.’ Why? Because software is only as good as its weakest link. Consider: what do you call software that is 99.9% perfect? Obviously, ‘0.1% imperfect.’ For avionics then, what are the presumed odds that the 0.1% imperfection will manifest itself via an inflight anomaly? A near certainty.”

Explaining further, he writes:

Therefore, we cannot provably state that software is perfect. Thus aviation takes a different approach. Since we cannot readily prove our avionics software is perfect, we do the following instead:

1. Define and follow a strict development “process” (DO-178), with increasing rigor for increasing criticality.
2. Maximize error prevention.
3. Recognize we cannot prevent every possible error, so institute error detection.
4. Accept that error detection is good, but error mitigation is divine.

 
[/stextbox]

Hilderman also advises care in the implementation of the standards. “DO-178C is not prescriptive therefore doesn’t cite a recipe; some developers wrongly believe they can take shortcuts. But when taken as an ‘ecosystem’, DO-178C’s objectives clearly require detailed requirements, independent Quality Assurance proof of verification, proven transition criteria, and full checklists to prove ‘innocence’ – otherwise the ‘innocent’ are assumed to be ‘guilty’ and do not achieve certification.”

Arvidsson says this standard has to apply to all software on the aircraft and explains how this fits into what they’re currently doing with the Gripen E,”Earlier when we had the older generations of computers, they didn’t have enough capacity so we had to integrate all the software in one system. We had both the tactical and the flight critical in the same computer and the same architecture. What we’re now doing is totally separating the tactical software from the flight critical software and going for this qualification, which applies on the flight critical software as well as the tactical system. DO-178C tells us how we need to verify our software to a very high – much higher standard.”