X C E L L E N C E I N A U T O M O T I V E A P P L I C AT I O N S
Application SWC
Actuator SWC
Sensor SWC
AUTOSAR Interface
AUTOSAR Interface
AUTOSAR Interface
AUTOSAR Software
Application SWC
Memory Block
AUTOSAR Interface
Host Processor
CPU Software
Memory & Registers
AUTOSAR Runtime Environment (RTE) EPP/FPGA PLATFORM Standardized Interface
Operating System
Standardized AUTOSAR Interface
Standardized Interface
Standardized Interface
AUTOSAR Interface
Services
Communication
ECU Abstraction
Standardized Interface
Standardized Interface
Standardized Interface
AUTOSAR Interface
BSW CPU Processor
Standard Hardware Peripheral
Memory Block
Complex Drivers
Programmable Logic
Standardized Interface
Basic Software
MCU Abstraction
Standard Hardware Coprocessor
Custom Hardware Coprocessor or Accelerator
ECU Hardware
Figure 2 – Porting of the AUTOSAR ECU architecture to an FPGA platform
At the bottom, in black, is the hardware or physical layer, consisting of the MCU itself—that is, the CPU and some standard peripherals attached to it. Above the microcontroller, the basic software (BSW) is decomposed in three layers: microcontroller abstraction layer (MCAL) in pink, ECU abstraction layer (ECUAL) and complex drivers in green, and services layer (SRV) in purple. These three layers are organized, in turn, into several columns or stacks (memory, communication, input/output and so on). Close to the hardware components is the microcontroller abstraction layer. As its name suggests, this layer abstracts the MCU. The goal is to have a hardware-independent API that handles the hardware peripherals present in the microcontroller. Next up, the ECU abstraction layer abstracts the other smart devices placed in the ECU board, typically in contact with the MCU (for example, system voltage regulator, First Quarter 2012
smart switching controllers, configurable communication transceivers and the like). Next, the third layer is the services layer. This layer is almost hardware independent and its role is to handle the different types of background services needed. Examples are network services, NVRAM handling or management of the system watchdog. With these three layers, AUTOSAR defines a set of basic software functions that sustain, under a specific hardware platform, all the functionality conceived from higher levels of abstraction to the automotive ECU. The fourth layer, the runtime environment (RTE), provides communication services to the application software. It is composed of a set of signals (sender/receiver ports) and services (client/server ports) accessible from both the upper layer of the BSW and the application layer (APP). The RTE abstracts the application from the basic software and it clearly delimits
the line of the software-stacked architecture that separates the generic and exchangeable software code (APP) from the particular and hardwaredependent code (BSW). In other words, the RTE makes it possible to isolate the software application from the hardware platform; therefore, all software modules running above the RTE are platform-independent. Above the RTE, the software architecture style changes from layered to component-based through the application layer. The functionality is mainly encapsulated in software components (SWCs). Hence, standardization of the interfaces for AUTOSAR software components is a central element to support scalability and transferability of functions across ECUs of different vehicle platforms. The standard clearly specifies the APIs and the features of these modules, except for the complex drivers. The SWCs communicate with Xcell Journal
23