Software Tools: Automakers Continue to Push Suppliers for More

Coordinating the increasing network of software and hardware modules in today's vehicles requires forming a system model to account for all the interfaces. AUTOSAR provides a common framework for interface compatibility but it is just the beginning. In some cases, tool suppliers have added additional tools or additional capability to an existing toolset to handle the workload from increased software. Some of the newest changes in the software development and modeling tools focus on improved synchronization, software integration and software linking.

DEALING WITH INCREASED COMPLEXITY

To address the increase in software and increased complexity in today's vehicle architectures, companies have increased the number of engineers working on software and modified the design methodology. “We see different people with different questions nowadays than we saw two or three years ago,” said Oliver Niggemann, lead product manager, System and Function Design Tools, dSPACE International.

“A traditional view on EE architectures, on EE systems normally, was ‘what is the functionality from a control engineering point of view,’” he continued. “We do have established tool chains for that including TargetLink code generation from control engineering models.” However, modeling the software as well as the amount and distribution of software has become a challenge. “If you are creating one complex control algorithm for engine control that's one problem,” said Niggemann. “It's a very difficult problem but one that we have seen in the last few years and we manage to handle.”

Systems with sensor fusion, such as adaptive cruise control, have a distributed nature where different data comes together from several sources. With distributed algorithms, the problem is synchronizing different algorithms on different ECUs. “And it is a large set of different software modules and hardware modules interacting. This is a different challenge,” said Niggemann. “The development we saw maybe 10 years ago in telecommunication field we now see in the automotive industry — modeling software or software/hardware systems.”

Today, several ECUs have algorithms that communicate with each other and all the ECUs are developed by different companies. Models with compatible interfaces between software modules are essential for sharing work. Even though one team works on one controller, different developers work on different software modules. Coordinating this network of software modules and hardware modules requires a consistent model — a formalized methodology.

According to Niggemann, to cope with the complexity, many car companies developed informal approaches, in some cases Excel spreadsheets. Entries in the spreadsheet could include the ECU, the various software modules, interfaces, for example a global variable to communicate with a different software module, the name of the variable, and the type of the variable.

“If you do this for a large system, let's say, five ECUs, each ECU with 200 software components you are talking 1,000 software components, each having 10 interfaces,” said Niggemann. “Now you are talking about 10,000 interfaces, so the sheer complexity of the problem makes it very difficult to handle.”

Once a software architect or system architect does not understand the relationship of his portion of the system to the total system, and cannot communicate this architecture, problems increase and errors occur. With a formal model, such as AUTOSAR, a new interface is entered into the model. Designers now have a tool to check whether the interfaces match and verify if this software module meshes into the software architecture. This type of verification requires the ability to check that the interfaces are compatible.

“So the idea is really forming a system model that all the different people working on the project can refer to,” said Niggemann. “And from the system model, they can really verify whether their software module, their ECU, their part of the system fits into the overall picture.”

Since no single supplier has a finished, complete solution, several new methods are being developed. Today, the first new tools for new processes are appearing in this area. TargetLink and SystemDesk from dSPACE are a specific example. TargetLink, dSPACE production code generator, generates efficient C code directly from The MathWorks Simulink/Stateflow models. With this well-established tool, designers model their algorithm and automatically generate code for the ECU.

On one ECU, designers often model one software module or smaller amount of software modules within one TargetLink model. However, an ECU can have hundreds of software components, depending on the definition of a software module. As a result, a design picture must show the software modules on the ECU and how they interact. Previously, engineers would create a picture and show the software modules on the ECU or on a network of ECUs. Each of those software modules can be created using TargetLink.

Ten years ago, a dozen or so software components were relatively easy to track. Dealing with hundreds or more software components, the increased complexity makes it more and more difficult to handle the complete system. “Once the overall architecture picture is established, all of the various design sections need to work off of that picture,” said Niggemann. If something changes, it must be changed in the overall picture, so every designer knows about the change and can determine how it impacts their portion of the system. For example, the addition of a CAN signal or new software component must be considered for the overall system.

TargetLink provides the overall software and system architecture. SystemDesk is a recently announced AUTOSAR-compatible tool and also models the mapping between software components and the hardware topology.

SystemDesk was specifically developed for planning, implementing and integrating complex system architectures and distributed software systems. Developed in parallel with AUTOSAR, SystemDesk allows users to handle large ECU systems. Software architecture developments and changes can be handled more readily with an exchange format that allows a supplier to obtain the software architecture from a vehicle manufacturer.

“With SystemDesk you can use very high-level block diagrams, graphical dialog, to model the system and this system will be AUTOSAR compliant,” said Niggemann. Similarly, hundreds of software components can be implemented using TargetLink. Since TargetLink is also from dSPACE, automatically creating the framework for the TargetLink system, implementing the TargetLink system and transferring to SystemDesk is straightforward.

The changing methodology has increased the need to work cooperatively with other companies. For example, Elektrobit Automotive creates basic software such as operating systems or drivers for ECUs and dSPACE does not. Working on the application algorithm level, interaction between the two levels is essential for their customers' successful use of both companies' toolsets. While throttle control would be done by dSPACE, the driver would be created with a tool from Elektrobit.

Working with the other company verifies that the tools work together and has advantages for both companies. Since customers use the tools together anyway, when suppliers work together to check the tools' functionality, the customer encounters fewer problems. “I think we definitely see a lot of cooperation on a level of verification on whether our tools work together,” said Niggemann.

In general, this cooperative attitude can be oberved at many companies and in diferent areas. To support model referencing, dSPACE Real-Time Interface (RTI) provides automatic implementation of MATLAB/Simulink/Stateflow models on dSPACE hardware. Models in separate files can be integrated into other models via model referencing and code can be generated for them incrementally.

For model-based design, The MathWorks recently introduced Embedded IDE Link MU automatically deploys code generated from Simulink models into the Green Hills MULTI integrated development environment (IDE) (Figure 3). The new software enables seamless transition and execution of code on a wide range of embedded microprocessors.

Ansoft's AnsoftLinks facilitates the transfer of design databases from third-party EDA layout tools and Mechanical CAD (MCAD) packages into the company's electromagnetic field simulation products. In addition to EDA links for a number of tools offered by Cadence, Zuken, Mentor Graphics and Synopsys, the software has MCAD links to support common file formats, such as IGES, STEP and Pro/E (refer to Figure 4). Specific functionality includes enhanced automation for Mentor Graphics Expedition translation and support for Cadence Allegro/APD v15.5.

While it does not qualify as cooperation at the company level, synchronizing different bus systems has been an issue in the past. With a FlexRay bus added to provide high-speed control, Vector CANtech developed the VN7600 FlexRay/CAN USB interface. As shown in Figure 5, the VN7600 is a bus interface with two FlexRay channels and three CAN channels in one device. This allows simultaneous access to both bus systems with just one hardware module and simplifies synchronization of the different bus systems with highly precise timestamps on a common time base.

At the recent SAE 2008 Hybrid Vehicle Technologies Symposium, several software suppliers displayed tools for hybrid vehicles. With hybrid development accelerating, software tools have also expanded, including tools that interface to accepted model-based development tools from The MathWorks and others.

One of the functions of ETAS INTECRIO V3.0 is the integration of MATLAB/Simulink models as well as the company's ASCET models and C code modules.

In addition to linking to its own ThermNet thermal simulation software, Infolytica Corporations MagNet can be invoked by ActiveX compliant applications including MATLAB.

One final example of tool linking is MotoTron's Moto-Hawk. This development tool allows users to create Simulink diagrams that run on its embedded control modules providing a prototyping system for Simulink/Stateflow users.

Since AUTOSAR provides standard file formats at different steps of the development process, it is much easier for toolmakers and users to couple tools together. As a result, software and tool suppliers can compete and cooperate with each other much easier.

“With AUTOSAR being a different kind of a model, a bus of TargetLink, Simulink, we will see in the future both levels interacting,” said Niggemann. He expects to see code generators in Simulink and Target-Link that will write the algorithm and on top possibly even the software architecture system models. “The development we are going to see in the next years is that the system models also become simulatable — that you can simulate a network of different ECUs on the PC,” said Niggemann.

Randy Frank is president of Randy Frank & Associates Ltd., a technical marketing consulting firm based in Scottsdale, AZ. He is an SAE and IEEE Fellow and has been involved in automotive electronics for more than 25 years. He can be reached at [email protected].