Software - Security

In 1996, when the first Ariane 5 rocket exploded only 37 seconds after lifting off from the mangrove swamps of French Guiana, software was at fault. The problem—investigators found—was that engineers had adopted a module from Ariane 4 without testing it. The purpose of the software was to convert the rocket’s speed from a long floating point number into a shorter data format. This was no problem for Ariane 4, because it was impossible for the number to exceed the upper limit of the abbreviated format. But with the more powerful Ariane 5, this occurred within half a minute, and the computer went down. The resulting loss wiped out more than half a billion euros.

Ariane 5’s unfortunate fate illustrates the extent to which software has become safety-critical—and the dramatic need for flawless quality. "In the old days, you would do what was known as a ‘walk-through,’ accompanied by an experienced colleague," explains Reinhold Achatz, who heads the Software & Engineering division at Siemens Corporate Technology (CT). "Given the complexity of today’s systems, we have to find alternatives, otherwise software wouldn’t be ready until years after the hardware."

With this in mind, software engineers determine whether the rules of the language used—that is, the software’s syntax—have been respected. For safety-relevant applications, a formal verification of the program sequence’s logic is conducted. The problem with this is that testing takes up a large share of any software project. "Tests and unscheduled debugging can consume up to 80 % of a major project’s time budget," Achatz explains. Experts are therefore examining how to accelerate this process.

In the past, expensive capital goods such as aircraft and power plants would always feature redundancy on critical control systems, with the result that codes had to be developed for two or three independent hardware platforms. This meant, however, that several development teams were required, and there still was no guarantee that errors wouldn’t be carried through from the design stage to the program itself. Engineers would much prefer the kind of exact implementation offered by programming in specific model languages.

A Dictionary for Every Problem. Model Driven Development (MDD) may help to solve this problem by bringing technology and software closer together (see  Taming Complex Systems). A company-wide platform coordinates the project (www.omg.org). "Regardless of whether it was a car radio or a railroad switching system, programmers in the past had to get by with one and the same programming language. MDD provides a kind of dictionary for each and every technical problem," explains Andrey Nechypurenko from Siemens CT. In other words, a model language is developed for each task. The symbols in the flow diagram are task-specific. "Engineers don’t talk in terms of loops and calls, they have their own language to open valves or run motors up to speed," explains Nechypurenko. The actual programming is undertaken by software agents. "This reduces the number of errors, since less code has to be written by hand," says Rainer Hochecker from IBM. "Using MDD, we completed a 40-month project in 21 months, and the number of errors fell by a factor of 17."

Worldwide, only a few major software projects have as yet been completed with MDD, because the decision in favor of a new process always means a long-term commitment. "Our initial experience with real projects has been very encouraging," says Martin Rothfelder from CT. "The technology will be ready for use in one to two years."

Using similar semiautomatic tools, security specialists also analyze the code for potential weaknesses. And they’re not only looking for the classic bug, which can crash the computer; they’re also hunting for design faults, which present a hidden risk and may well have been introduced during the design stage. For example, banking software from Siemens must be capable of administering dozens of different encrypted communications channels—without giving a potential eavesdropper a chance to decode the confidential content.

One of the scientists with whom Siemens works most closely in the field of security and reliability technologies is Prof. Peter Liggesmeyer, Director of the Fraunhofer Institute for Experimental Software Engineering in Kaiserslautern, Germany. Liggesmeyer is primarily involved in the security of embedded software. "The analytical methods commonly used are sometimes unable to answer important questions," he explains. With fault tree analysis, for instance, it is impossible to decide whether data is being processed at sufficient speed. "Fault trees link cause and effect, for example when system components fail, but they don’t take time into account." Liggesmeyer’s research group develops tools for problems like these. "This new approach involves greater effort at the beginning of a project, because a great deal of energy goes into producing clean descriptions," he explains. "Later on, though, you don’t have to go back and iron out errors." Furthermore, a model that has been carefully developed and tested can be reused much more easily. One stipulation, however, is that the model’s compatibility with new components—unlike the case of Ariane 5—has been properly resolved.

Bernd Schöne