Design Article
AUTOSAR proof-tests vehicle electrical design at every level
Bill Chown, Michael Seibt, Mentor Graphics Corp.
7/23/2010 5:01 AM EDT
Taking abstraction to the next level
Adding the RTE level to the authoring process represents a much more detailed abstraction level. Many more parameters are required to describe this level, since it incorporates more of the implementation platform for the software configuration. In return for this added effort, the impact of OS capabilities such as scheduling and task mapping can now be considered.
Figure
3: AUTOSAR RTE Level
Moreover, this authoring step can map the SWCs to the control units, and in doing so determines the nature of communication within and external to the ECU. The degree of intra-ECU communication provides information on the CPU load and the allocation of resources. External communication, too, is a factor now. This communication takes place below the RTE via the Basic Software. Interactions with memory, diagnostics, or communication services, as well as platform-dependent support, are provided within the BSW. Figure 3 is a simplified view of the layers discussed so far, and it also depicts a Gateway function that enables typical distributed ECUs to act in concert. Figure 4 elaborates on this view with a close-up of a single ECU’s contents. Again, the BSW elements below the RTE layer are all standardized, while the SWCs above are proprietary (but AUTOSAR-compliant) designs dedicated to purposes such as user controls or sensors and actuators, to cite simple examples.
Figure
4: The topology of a complete ECU
Using the details developed in
the foregoing VFB and RTE level design work, a full-featured simulation
platform that is 100 percent compliant with AUTOSAR is the tool of choice for
the next step. During this simulation, the Runtime Environment (RTE) is integrated,
including OS tasks and threading.
At the time the task-level content is developed, it is possible to study and optimize scheduling strategies. Software component models can be integrated into the simulation as C-/C++ code or precompiled libraries. A tool such as Mentor Graphics Virtual System Integrator (VSI) offers both the traditional source code view and a graphical view, using AUTOSAR graphic notation in the form of software components or executable diagrams. Both views are synchronized and support the full range of debug functionalities such as Set BreakPoint, Step, and many more. Advanced AUTOSAR development tools with these capabilities support black-box (system) testing using high-level constructs such as “temperature,” as well as white-box testing that probes deeper levels of detail. Figure 5 depicts a screen from such a tool, showing a simulation in progress.
Figure
5: AUTOSAR-compliant integration tool display showing a simulation in progress.
Again assuming a full-featured
tool, breakpoints can also be set, activated, or deactivated not only in the
code listings but also in the AUTOSAR diagrams. A user might position a
breakpoint at an SWC port or an executable’s access point, for example. Internal
variables such as data elements or inter-Runnable variables are displayed in
the variables window. Registers and variables can be changed at run time, allowing
simulation scenarios to be modified dynamically and speeding up the
optimization process. These are capabilities that developers need and expect
from a development environment.
Next: Title-3
|
|
|
|
|
