Software analysis: reading source codes

One approach to tracking down the various glitches in control units is to analyze the source codes. “This involves using special analysis programs that investigate the source code for errors and bugs,” explains Dirk Johanson, who heads the Software Analysis team in Schmerler’s department.

Roughly speaking, this procedure can be compared to the critical analysis of a text. Any text – a recipe, say – can be written in a variety of ways and with a choice of different words.

Irrespective of the style or vocabulary, however, there are valid rules of grammar and spelling that must be obeyed: a capital after a period, for example, or the appropriate verb-ending with different pronouns – for example, “we like to read books” and not “we likes to read books.” Today’s word-processing programs generally feature an integrated spelling and grammar check that highlights mistakes and even automatically corrects them.

Programs that analyze codes work in a similar way, albeit at a much more complex level. Were it to be printed out, the source code for a vehicle control unit would fill thousands of pages. The flood of data would be simply impossible for one person to manage. The answer is therefore to run the source code through a variety of code-analysis programs. “These programs,” Johanson explains, “identify not only straightforward program errors such as a division by zero but also parts of the program that never get executed and erroneous memory access.” At the same time, they also spot dubious data – when, say, a control unit shows a reading of 350 kilometers per hour for the car speed. Such a speed may be theoretically feasible – but not in a standard road vehicle.

Depending on the precise objective of the analysis, Daimler researchers have access to a variety of tools with which to investigate issues such as resource use or runtime errors. On completion of the code analysis, they have a list of all the errors and bugs. With the help of this list, the specialists can begin to iron out the problems. “As a rule, we don’t carry out this part of the work ourselves but instead tell the software developers at the supplier where they need to look,” Schmerler explains.

House calls

In practice, this means that the code analysts from Daimler Research often spend a few days at the supplier’s operations in order to investigate the source codes and then make appropriate recommendations. That way, the codes need never leave the supplier – an important consideration, since the software for the control unit is, of course, that company’s intellectual property.

Johanson underscores another important aspect: “In the course of code analysis, we merely take a look at the source code rather than actually running the program in a test procedure. In other words, we just look at the recipe, rather than testing the dish to see if it tastes good.” Since functionality tests cannot cover every possible combination of errors, code analysis is carried out to additionally pinpoint the problem areas.

That said, the software must be absolutely bug-free by the end of the analysis. The only leeway the experts have here is in judging how strictly the formal rules must be obeyed. “The tools we have for code analysis are like a sieve of varying mesh size – we can tailor them to the specific case in hand,” adds Johanson’s colleague Steffen Görzig, who heads the Software Reuse team in Hohlfeld’s department.

Searching for runtime errors

One such case involved the Common Powertrain Controller (CPC), which is used in light-duty and heavy-duty trucks, buses, and also Unimogs. Given that no two commercial vehicles are exactly the same and that the onboard electronics also therefore vary considerably, a CPC must be able to function with many different variants. However, it must also communicate reliably with the 30 or so other control units installed in a typical commercial vehicle. “We kept on getting runtime errors but had absolutely no idea where and when they were originating,” Steffen Görzig recalls. And because the team was unable to re­produce the errors, the only alternative was to carry out a code analysis of the extensive software in its entirety, which ultimately led to the discovery and resolution of the problem.