ETAS AUTOSAR Overview
ASCET V6.4 AUTOSAR User’s Guide 19
2 AUTOSAR Overview
Today, special effort is needed when integrating software components from different
suppliers in a vehicle project comprising networks, electronic control units (ECUs), and
dissimilar software architectures. While clearly limiting the reusability of automotive
embedded software in different projects, this effort also calls for extra work in order to
provide the required fully functional, tested, and qualified software.
By standardizing, inter alia, basic system functions and functional interfaces, the AUTOSAR
partnership aims to simplify the joint development of software for automotive electronics,
reduce its costs and time-to-market, enhance its quality, and provides mechanisms required
for the design of safety relevant systems.
To reach these goals, AUTOSAR defines an architecture for automotive embedded software.
It provides for the easy reuse, exchange, scaling, and integration of those ECU-independent
software components that implement the functions of the respective application.
The next sections briefly describe the AUTOSAR process for the development of application
software components. For more detailed information the reader can refer to the AUTOSAR
documents at the AUTOSAR website: http://www.autosar.org/.
2.1 AUTOSAR Basic Approach
Application software is the name given in AUTOSAR to vehicle functions. Each application is
decomposed into one or more
software components
(SWCs), which are designed to be both
CPU- and location-neutral. An AUTOSAR application software component can be mapped to
any available ECU during system configuration.
The abstraction of the SWC environment is called the
virtual function bus
(VFB). In each real
AUTOSAR ECU, the VFB is mapped by a specific, ECU-dependent implementation of the
platform software. The AUTOSAR platform software is split into two major areas of
functionality: the runtime environment (RTE) and the
basic software
(BSW).
The BSW provides communications, I/O, and other functionality that all software
components are likely to require, e.g., diagnostics and error reporting, or non-volatile
memory management.
Application SWCs have no direct access to the BSW. This means that components cannot,
for example, directly access operating system or communication services. The
runtime
environment
provides the interface between software components, BSW modules, and
operating systems (OS). Concerning the interconnection of SWCs, the RTE acts like a
telephone switchboard. This is similarly true of components that reside either on single ECUs
or networked ECUs interconnected by vehicle buses.
In AUTOSAR, the OS calls the runnable entities of the SWCs through the RTE. RTE and OS
are the key modules of the basic software with respect to controlling application software
execution.
ETAS has been supplying the auto industry with automotive operating systems for more
than a decade: ERCOS
EK
and RTA-OSEK. The RTA-RTE AUTOSAR Runtime Environment and
RTA-OS AUTOSAR Operating System extend the RTA product portfolio with support for the
key AUTOSAR software modules. Based on their AUTOSAR interfaces, basic software
modules from third-party suppliers can be seamlessly integrated with RTA-RTE and RTA-
OSEK.