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.

Figure 1. For graphical software architecture modeling, dSPACE’s SystemDesk has component diagrams for modeling software components, including ports and interfaces. Using these software components, the composition diagram models software architectures and functional networks.

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.”

Figure 2. With dSPACE’s SystemDesk design tool and TargetLink production code generator, previously created function models can be integrated at the system level.

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.”