Re-engineering software

Whenever a particular software package is repeatedly enhanced over the years, the organic growth involved can often lead to the program becoming more and more unwieldy. Although the software continues to function to a large extent, it sometimes carries along algorithms that are no longer needed, and inexplicable errors start to occur. As a result, people who are new to the program have little chance of deciphering the source code. And after a certain point it becomes impossible to integrate new functions without creating errors.

In cases like this, where something more extensive than code analysis is required, Daimler researchers turn to a procedure known as software re-engineering — in other words, the reorganization of complete programs. “We take a look at what’s already there and develop the positive features,” says Hohlfeld in reference to the work done at his Software Structures department.

As an example, he names the DSR traction control system installed in buses and the Mercedes-Benz truck models Atego, Axor, and Actros. This uses the speed of the wheel’s rotation to calculate the momentary load distribution between the vehicle’s axles and thus determine the optimal distribution of the braking force between the axles.

Re-engineering 20 years on

For Hohlfeld and his colleagues, there were several good reasons for reorganizing the DSR software package. To begin with, the software had been introduced in the Actros as long ago as 1987 and had therefore expanded over the years. It was thus time to restructure the program and thereby make it easier to maintain and enlarge it in the future. The objectives were to boost reuse of the software in company vehicles, cut the associated costs, reduce the likelihood of bugs, and facilitate the quick and easy addition of enhanced functions. At the same time, the vehicle developers also wanted to find a second supplier for the component, who could then be provided with the requisite know-how in a clearly structured form.

“We started off by removing a number of elements from the software, but we retained a lot of the functionality and restructured it,” says Görzig. “We’re not out to reinvent the wheel on projects like this. The important thing is to reincorporate all the proven algorithms in a viable form in the re-engineered package and document them in such a way that people who are new to the software can understand them.”

Aid for developers

As the example of the DSR software shows, the work of the software specialists has greatly helped their colleagues in truck development. “Thanks to the software experts at Daimler Research, we’re now able to split the current series-production software into small, easily manageable parts. That means we can concentrate more on the actual nitty-gritty of the application, namely expanding the functionality, independently of the hardware. This enables us to more efficiently enhance the software while also reducing the risk of bugs,” says development engineer Stephan Reichle from the Brake and Chassis Electronics department at Truck Engineering.

For the researchers, the prime objective of re-engineering is to create a “clean” software architecture. To date, such work is generally conducted fairly late in the day, by which time the software structures have become complicated and thus require a lot of time and effort to sort out.

The teams in Hohlfeld’s department are therefore also working on methods of at least partially automating the re-engineering process. “The truly ideal scenario,” says Görzig with a grin, “would be one in which we could re-engineer the software simply at the press of a button.”