Mercedes-Benz R&D North America: Enhanced Safety and Efficiency for the Software Design Process at Mercedes-Benz

In particular, MBRDNA was looking to enhance the capabilities of the control software for their E-Drive components. The team, located in Redford, MI (USA), has already adopted model-based development as its key development approach for embedded control software design. As part of this, the software model serves as the fundamental artifact in the development process – the functional integrity and the coverage of the intended functionality are primarily verified at the software model level. The existing software models used for production are periodically enhanced to incorporate more and more functionality as part of a continuous improvement process. The E-Drive software model in question at MBRDNA serves as the basis for the controller of an electric drive system. It manages functions such as torque and traction of the electric drive. This controller software is also used for 48V systems, pure E-Drive systems, and fuel cell programs.

The MBRDNA strategy was to first implement the basic functionality for the software. As more complex requirements and additional project stakeholders, such as new developers, testers, and calibrators, got involved, MBRDNA identified the need to "manage complexity" in order to keep the complex software model relatively easy to understand and promote straightforward communication about it among the team. The software model had grown significantly, and this became the main driving force behind reviewing the basic model. The software models’ functional testing team, in particular, was often required to invest extra effort in testing the software module and the units involved.

Developing a Systematic Approach for Software Model Refactoring

MBRDNA first defined a set of objectives for refactoring software models. The main objective was to improve the testability and understandability of the model by reducing the complexity. MBRDNA was looking to reduce both subsystem-level complexity and also complexity at the level of the entire integrated software model. MBRDNA complies with the ISO 26262 safety standards, so it is essential for them to ensure that the units and models are well structured and do not contain overly complex parts, as these frequently cause issues in testing and in general. Overly complex parts have to be split up into less complex and smaller units – ideally containing one dedicated functionality per subsystem. An additional objective is to identify potential library elements, as this will further reduce overall model complexity. MBRDNA’s approach is to drive automation to the highest level. In line with this, MBRDNA set about looking for a model architecture enhancement tool to support and monitor the refactoring results. The long-term intention was to verify if such a tool can help support continuous architecture monitoring and optimization as part of the defined software model design process.

Finding the Right Tool for the Job

To support the model refactoring project, model metrics from MES* were selected. These compute the local complexity of software models for each subsystem and also deliver the global model complexity. This function also points the user to so-called hotspots of the model. Hotspots are subsystems of the model that should be revised and refactored. To further optimize impact of this function, MBRDNA took advantage of their flexibility, customizing them according to their specific environment. In particular, MBRDNA added specific function blocks and defined custom scaling factors to the configuration of the MES model metrics*. Due to this easy configurability, a wide range of metrics could be delivered, identifying problematic parts of the MBRDNA models accurately. This function provides both a qualitative and a quantitative analysis. The quantitative analysis includes the overall global complexity of the software module. This information is needed in the "re-architecting process" and for the further modularization of software, where global complexity is used to determine which oversized software module should be split into several software modules. The qualitative analysis provided MBRDNA information about error-prone hotspots within a particular software module. Here, MBRDNA is specifically interested in the local subsystem complexity and how to limit complexity in a smart way.

Remodeling Techniques Applied

Based on the metrics delivered by MES tools, MBRDNA developed and employed a range of techniques to refactor the identified software model parts:

• Systematic splitting up of overly complex subsystems into a set of less complex, functionally coherent subsystems.
• Use of the MXAM/MXRAY^* clone detection to detect redundant elements/blocks in the model (e.g. blocks for Polynoms) that are used repetitively. These redundant elements are then added to the MBRDNA specific block library or to a referenced model. The basic idea here is to avoid redundant model components that have to be reviewed and tested individually.

* Model metrics were originally part of MES M-XRAY (MXRAY)^®. The MXRAY features have since been integrated in to MES Model Examiner^® (MXAM) where they are continuously evolving.