Body Electronics
Round-trip engineering is key to AUTOSAR
In an AUTOSAR-based development process a number of different tools are used and it is crucial that these tools work smoothly together. In this article, Mentor Graphics and Mathworks demonstrate that round-trip engineering is essential for tool interoperability. It enables engineers in the automotive industry to follow an iterative development processes.
After seven years of development, AUTOSAR has finally arrived in series production. For the development of AUTOSAR-compliant control units, engineers use a variety of different tools, which are applied in different phases of the process. The software architecture is generated with an authoring tool such as Vehicle Systems Architect (VSA) from Mentor Graphics, while the functional behavior of AUTOSAR software components is modeled with tools such as MATLAB and Simulink from MathWorks. Vehicle manufacturers and suppliers use different workflows – top-down or bottom-up – depending on whether they want to develop control-unit functionality from scratch or on the basis of existing software and models. One of AUTOSAR's strengths is the standardization of interface description formats of various design artifacts, e.g. software component descriptions.
These descriptions, along with the models of the above mentioned tools, make it easier for development teams to collaborate and communicate amongst themselves. This also improves OEM and supplier relationships throughout all development phases. It is essential that the tools in use support all over design iterations – the so-called round-trip engineering. The challenge here is to make sure that intermediate results with regard to AUTOSAR artifacts, such as ports, interfaces and data elements, remain consistent when they are exchanged between different tools. This is especially important in the interaction between tools used in Model-Based Design to model functional behavior and the AUTOSAR authoring tool for architecture modeling.
Figure : AUTOSAR Software Architecture
AUTOSAR meets Model-Based Design
Model-Based Design has become an important component in vehicle manufacturer and supplier development processes. Electronic control units are complex in terms of functionality, connectivity and variants, therefore automotive engineers must constantly optimize their development processes to keep up with the competition and stay true to the AUTOSAR motto: “Cooperate on standards, compete on implementation.”
While simulations provide insight into the dynamic and algorithmic aspects of a system, models are usually used for various design tasks, such as:
- Use as executable specifications
- Communication of component requirements and interface definitions between OEMs and suppliers
- Creation of virtual vehicle prototypes for developing algorithms including plant models
- Automatic code generation for production embedded systems.
Model-Based Design helps focusing on error prevention and early fault detection. By means of an early verification and validation in the project, the risks and costs of late bug detection in the development process are significantly reduced.
AUTOSAR requires engineers from the automotive industry to take the next step and focus on functionality independently from topology. Traditionally, automotive engineers have designed functionality based on a specific topology – single module or distributed. Within AUTOSAR, a layer of abstraction is introduced so that functionality is built from software components that are independent of the specific topology of the number of nodes or variants.
Model-Based Design with Simulink and Embedded Coder gives engineers the freedom to use one model for various project tasks and to develop it further. In very early phases the functional behavior is validated by means of simulation. Later, a more detailed version can be tested directly in the vehicle with the help of rapid prototyping hardware, until the model is at the stage when the AUTOSAR production code can be generated. For this purpose, standard Simulink elements can be used, which can be intuitively mapped onto AUTOSAR artifacts. For example, a model reference block can map an AUTOSAR software component, or an Inport block can map an AUTOSAR port with data elements. No separate AUTOSAR blockset is required, meaning engineers can concentrate on modeling the functional behavior.
Top-down design versus bottom-up
Model-Based Design supports the concept of AUTOSAR. Top-down consideration begins with system architecture. An authoring tool such as Volcano Vehicle Systems Architect (VSA) from Mentor Graphics enables engineers to describe the software architecture, including software components and internal behavior, control unit topology, and the communications matrix and associated mappings. Consistency checks and design rules, which can be either built-in or user-defined, help testing imported data sets for accuracy and completeness.
Figure : VSA - Simulink roundtrip workflow. For full resolution, click here.
Exporting AUTOSAR description files facilitates simple interaction between tools for developing functional behavior and control algorithms using Simulink, which can import these descriptions. During the import of software component descriptions, skeleton models, which contain all relevant information such as interfaces and internal behaviors, are automatically generated. Based on the skeleton models, developers can design the functional behavior in the usual manner as described above. When the model is finished, AUTOSAR C code is generated with Embedded Coder; at the same time, a new software component description is exported during code generation, which can then be imported into VSA for further integration. Another consistency check, as mentioned above, is performed at this stage to complete the round trip for a top-down approach.
On the other hand, numerous models for functions developed prior to AUTOSAR already exist which are used in series production. In such cases a bottom-up approach is preferred wherein AUTOSAR-specific information needs to be added to the detailed models. Once this step has been completed, AUTOSAR compliant C code and corresponding AUTOSAR software component descriptions are generated which can be further processed by the authoring tool.
The challenge of round-trip engineering
In ongoing projects, all design phases, which go through several iterations, are subject to changes. In practice this is a big challenge for engineers, especially when different commercial tools are used – which are often combined with in-house solutions. Many of these tools have only partial coverage of the AUTOSAR meta-model. This can lead to data loss or even corruption, especially when importing or exporting data. The situation becomes even more difficult by the numerous releases and revisions of AUTOSAR which are now available, and which often lead to incompatibilities among each other.
VSA provides numerous import and export options and can read or extract AUTOSAR data (among other functions), thus making the data available to other tools. The VSA meta-model technology used guarantees 100-percent coverage of the AUTOSAR meta-model and prevents data loss during importing or exporting.
UUIDs (Universal Unique Identifiers) and shortnames ensure that individual AUTOSAR artifacts are clearly recognizable during round-trip engineering. These concepts are supported by VSA as well as by MATLAB and Simulink. On this basis, tools from MathWorks and Mentor Graphics work smoothly together and enable a consistent data transfer from one tool to another.
Furthermore, VSA also provides an AUTOSAR compare and merge function, which allows various AUTOSAR data sources to be merged into one consistent file using shortnames or UUIDs. This functionality is essential, particularly in the iterative processes of round-trip engineering.
ConclusionVSA, MATLAB, Simulink, and Embedded Coder support a round-trip design approach and consequently offer an intuitive combination for AUTOSAR development. Data can be exchanged in two directions, and relevant data can be kept consistent in, and further processed in the respective tool.
Authors: Guido Sandmann is Automotive Marketing Manager, EMEA, at MathWork. Michael Seibt is Product Manager at Mentor Graphics
Sources[1] AUTOSAR: www.autosar.org
[2] VSA User Guide
[3] Model-Based Design: www.mathworks.com/applications/controldesign/description
[4] MathWorks AUTOSAR Support: http://www.mathworks.com/automotive/standards/autosar.html
[5] Simulink: www.mathworks.com/products/simulink
[6] Embedded Coder: www.mathworks.com/products/rtwembedded
- No news
- In Formula One, Freescale is in the pole position
- Volvo evaluates flywheel hybrid drive - fuel savings of up to 25%
- Bosch tests automatic driving on the Autobahn
- Bosch highlights radar technology for safety-relevant driver assistant systems
- Toyota utilizes SPARK Pro programming language in ultra-low-defect software
- Bosch stresses high costs for lower fuel consumption
- TRW succeeds with electrical power steering system in China market
- Universal charger connects plug-in hybrids globally to the grid - as long as it is a Porsche
- Students build electric racing car
- Autoliv provides the "eyes" for driver assistance systems
- Open Standards and Product Differentiation
- AV architecture on ARM Cortex SOCs
- Using Ethernet Applications to Optimize Automotive Electronics Platforms
- What's New In Power Management Electronics
- Communications between a plug-in EV and the EV supply equipment
- TTEthernet Scalable Real-Time Ethernet Platform
This site contains articles under license from EETimes Group , a division of United Business Media LLC.
