It’s all in the model

Hardware-in-the-loop test rigs are used to test the functionality of networked components (in this case truck lights) in a computer-simulated vehicle. 

 

Just a very brief lapse of concentration can have potentially fatal consequences: The driver of a 32-ton tractor trailer fails to notice the warning light on the dashboard because he’s looking at the stereo display while attempting to change the radio station. But the Active Brake Assist (ABA) system in the Mercedes-Benz Actros goes into action, alerting the driver to the danger up ahead by briefly applying the brakes. This is all it takes to return the driver’s attention to the road, where a traffic jam has suddenly formed, seemingly out of nowhere.

The driver of the Actros perceives the danger instantly, hitting the brakes hard and coming to a safe stop before his truck can collide with the vehicle in front. Without the electronic assistant, within 30 minutes traffic reports on the radio would likely have been announcing “The A8 autobahn is completely blocked due to a traffic accident.” And newspaper headlines the next day would likely have told a tragic story of a highway accident caused by a driver’s failure to brake in time.

ABA relies? on a proximity radar and a control unit. But the key component is the software, which has to differentiate between a “normal” traffic situation and a dangerous one — in realtime, and with extreme precision. If the situation gets tricky, the electronic assistant initially responds by issuing optical and acoustic warnings. Should the driver nevertheless fail to react, the system will automatically initiate an emergency braking maneuver after determining that a rear-end collision can no longer be avoided.

No errors allowed

“Just imagine a software error causing such a system to engage the brakes without any warning, while a vehicle is traveling at normal highway speed,” says Stefan Schmerler — and it doesn’t take an expert to figure out what the result would be. Schmerler is one of the Mercedes engineers responsible for ensuring that such a disastrous scenario will never take place. “Our formula for excluding such potentially fatal mistakes is error-free software at the push of a button.” Schmerler is Director of the Methods and Tools department in the Daimler Research Software Lab, which is headed by Klaus Grimm. One of the department’s projects at the moment is “Model-Based Development of Assistance Systems (MBD).”

The core of this project is a set of methods and tools that have made it possible to develop software for safety-critical systems that can attain a level of quality corresponding to Schmerler’s formula — in terms of defining the software requirements, creating the software itself, and testing its functionality and freedom from error.

Ingo Kreuz, an IT specialist and the new MBD project manager, and Dirk Johanson, who previously managed the project and oversaw its successful transfer into commercial vehicle series development, are well-versed when it comes to explaining the special aspects of MBD. “You used to have a set of specifications that defined the requirements for each component,” explains Johanson. “Using this documentation as a basis, a programmer would then write the software for the new control unit.”

As when writing text, it’s possible that “typos” can occur and remain undetected, despite extensive checks. And while subsequent functional tests can help maintain software quality, empirical evaluation procedures — no matter how extensive — can never deliver 100 percent certainty. But absolute certainty is exactly what’s demanded of engineers like those who developed the braking assistance system used in the Actros. These engineers must be able to guarantee that no situation whatsoever — not even the most unlikely of events — will ever result in the system initiating an unnecessary emergency braking maneuver.

Managing complexity

Kreuz describes the difficulties that are involved in this tricky task: “Today’s vehicles are in effect rolling computers, with as many as 40 or even 50 control units on board. The associated requirement profiles or specifications for just one vehicle model can fill up 500 looseleaf binders. In other words, they’ve reached a level of complexity that makes it practically impossible to monitor everything completely and simultaneously.”

This is where the MBD project comes in. The basic idea here is to set up an additional level, on which the engineers initially incorporate the requirements for the control program into a function model. This model contains all of the input parameters necessary for the function, and also graphically depicts what should be done with them — in other words, how they should be processed, where the interfaces for transferring data from partial processing steps are found, and which actuators the control unit should ultimately regulate, and in what manner.

While this may sound as if the entire process is being made more complicated rather than simpler, the approach does offer several advantages, and one benefit is greater clarity. This is achieved because the graphic depiction of the overall function and sub-functions makes it possible for them to be reviewed more rapidly and checked for contradictions more easily than would be the case if hundreds of pages of text had to be checked.

The decisive aspect here, however (which is related to Schmerler’s “error-free software” claim), is that such a function model can be tested much more rigorously than would be possible with empirical function testing. To this end, Schmerler’s team employs automated testing and verification procedures. Simulations are run here to answer questions such as whether it would be theoretically possible for a certain model to allow an error to occur in a specific operating situation, however unlikely that situation might be.

Error-free software automatically

Johanson points out a third advantage: “Once you’ve created a secured function model, the programming occurs practically automatically.” He’s referring to “code generators,” which can translate such models directly into the C programming language, allowing the software to be written without the help of a programmer. And because these code generators themselves have been put through exhaustive tests, no “typos” can creep into the code during the fully automated process, which turns Schmerler’s “push of a button” goal into reality.

Schmerler cites a fourth benefit: “Model-based development also makes it much easier to transfer a particular function from a truck to a travel coach, for example, because many system sub-functions can be used with both vehicle types. So what we’ve got is a kind of toolkit with pre-secured modules, which not only speeds up the development processes but also lets us attain a far more advanced level right from the start.”

For the software specialists on Schmerler’s team, Active Brake Assist thus served as a “door-opener” in commercial vehicle development. But the new approach also quickly attracted the interest of other Group development departments — and Kreuz knows why: “Our colleagues are always telling us how happy they are that we’re able to offer them a closed tool chain with our model-based development approach.”