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.
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.
4: The topology of a complete ECU
AUTOSAR integration and simulation
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.
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.
David Patterson, known for his pioneering research that led to RAID, clusters and more, is part of a team at UC Berkeley that recently made its RISC-V processor architecture an open source hardware offering. We talk with Patterson and one of his colleagues behind the effort about the opportunities they see, what new kinds of designs they hope to enable and what it means for today’s commercial processor giants such as Intel, ARM and Imagination Technologies.