White Papers

This paper demonstrates the interaction and the interoperability of architecture and model-based design environments in five steps using the examples of MATLAB, Simulink, and Embedded Coder by MathWorks, as well as the AUTOSAR authoring tool Volcano Vehicle Systems Architect (VSA) by Mentor Graphics.

This paper discusses how round-trip engineering can be used as an iterative development process and describes interoperability between tools from Mentor and MathWorks.

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 in order to keep up with the competition. It is essential that the tools in use support all-over design iterations -- the so-called round-trip engineering. The challenge is to make sure that intermediate results with regard to AUTOSAR artifacts 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.

Proper safeguarding of safety-critical systems in an automotive environment cannot be ensured sufficiently without taking timing into consideration. The failure to observe timing constraints can lead to malfunctions and, in a worst-case scenario, can cause vehicle damage and personal injury. AUTOSAR 4.0 now supports timing constraints, but the standard, although very powerful, still is not able to address all aspects and requirements for electric/electronic (E/E) architectural design. However, alternative standards, such as EastADL2 and the Timing Extension (TIMMO) standard, have tackled this issue. This paper discusses a way to combine AUTOSAR with EastADL2 and the TIMMO timing language (TADL), enabling a consistent, top-down design approach at both the functional and timing levels.

The emerging automotive design software standard known as AUTOSAR (Automotive Open System Architecture) began as the product of an industry-wide effort among European auto makers and their suppliers. Its objectives are similar to those of software standards in other industries: to bring structure, clean interfaces and implicit methodologies to a process—in this case, the design of distributed systems within automobiles. FlexRay™ is a serial bus communication standard that has evolved over roughly the same time span as AUTOSAR. FlexRay came into existence as a solution for the shortcomings of the prevailing automotive bus standards, particularly the CAN protocol.

Like AUTOSAR, FlexRay counts many prominent automotive OEMs and suppliers among its advocates. Boasting much higher performance (in every respect) than other in-vehicle buses, FlexRay alone is suited for “x-by-wire” applications that must deliver absolutely predictable results for steering, braking, and so forth. What do these lofty aspirations mean to the designer who needs to get a complex array of automotive functions working together with high reliability? To the executive responsible for minimizing costs while delivering timely, compelling products to customers? To the end-users of tomorrow’s automobiles?

This paper describes several experiments designed to characterize jitter in an actual automotive application designed using FlexCAN, a CAN-based communication architecture. Large and variable jitter has been a liability of the CAN protocol. The paper also explains how FlexCAN reduces jitter by using a simple message scheduling technique that synchronized with control system applications.