Higher Level Protocols - CAN System Engineering - page 193

lot and the complexity is growing. At the same time there is a high demand to deliv-
er high-quality software, partly also due to the growing amount of functional safety-
related systems. Some of the original equipment makers (OEMs) react to this global
trend with own standardized software platforms, for example, the BMW Standard
Core . 1 This software platform was provided by BMW to the Tier 1 already in 1998.
Because of the existence of different OEM-specific automotive middleware, the
Tier 1 always needs to adapt their application software to these quasi-standards.
The integration costs of these adaptations are sometimes beyond the application
development costs. In parallel to these technical requirements, there is a change
in the market environment. The major sales regions are saturated. This forces the
OEM to change their strategy for vehicle production. In addition, niche markets will
be addressed with special vehicle models and the model change will be faster. The
pressure for vehicle development, and hence also for automotive software develop-
ment, increases.
The only way to develop more complex system in a shorter time—and still con-
trol them—is to standardize a horizontal basic software while reusing the applica-
tions more and more. A first step to the right direction is the AUTOSAR standard.
The following pages will give a brief overview about the AUTOSAR standard
by focusing the CAN-based communication path through the layered software ar-
chitecture.

4.2.1.2 AUTOSAR Concept

One of the main ideas of AUTOSAR is the clear separation of hardware-dependent
software from hardware-independent software. Therefore, an abstraction layer is
placed between the microcontroller hardware and the application software. The
AUTOSAR runtime environment (RTE) is on top of the layered architecture. It is
the only visible interface from the application point of view. Below the RTE several
software layers exist, from services via operating system (OS) down to the lowest
software layer, the microcontroller abstraction layer (MCAL). Figure 4.16 shows an
AUTOSAR compliant software architecture.
The AUTOSAR RTE defines the interface from the application to the basic soft-
ware. For data exchange, the RTE implements, e.g. a client-server and/or a sender/
receiver communication model.
All interactions of application software, called “application software compo-
nents” in the AUTOSAR language, run via the RTE. This results in a hardware-
independent application. This enables the exchange of applications among the dif-
ferent electronic control units (ECUs). If there is a lack of resources on one ECU,
e.g. no more random access memory (RAM) left to run a special RAM-intensive

1 Standard Core is a typical name for a complete automotive middleware respectively for the soft-
ware between application and hardware of an electronic control unit (ECU). Additional to the pure
runtime software a Standard Core contains support functions like a generic make environment or
complex configuration tools.