AUTOSAR Handbook

KPIT Technologies Ltd.

Validation R 3.x ASAM HIS-MISRA

Standardization COM
Microlayerdrivers VCI MigrationCAN R4.x
Migration R 3.x ARTOP RTE generation Customizable
MBD Consulting Testing CoE HIS-MISRA
eNOS Partner Testing MCAL
R 3.x In-vehicle network
ECU Validation
Configuration OSEK R 3.x BSW stack Mode
R 4.x
Tool chain Gateway
Standardization R 3.x drivers Partial OSEK Migration Training
ISO 14229 MCD3 API

MBD Management OSEK

MBD Network
Network VCI Management

OTX CT Specs
Networking ASAM CT-Spec Network Consulting Management

AUTOSAR ECU eNOS MBD

VCI
ASAM
AUTOSAR
MBD Tool qualification
Gateway
Tool chain Training Hardware
ASAM Training
ManagementMBD
MBD ASAM Optimization
Hazard Analysis MCD3 API

FUNCTIONAL SAFETY
Network

In-vehicle network drivers ECU CT Specs MCAL Tool qualification HardwareASAMValidation ASIL A, B, C, D Management
ECU
Partial ISO 15765 MBD Mode ECU
Management MBD
Validation Migration Validation
Validation Adaptation CAE Risk Assessment Scalablility
Complex

Specifications Testing
Drivers

Partial Networking
CT Specs eNOS
R 4.x In-vehicle CT BSW Stack OSEK hardware MBD MCAL Networking MCD3 API Testing
Optimization
ECU network R 3.x ODX BSW stack ECU ISO 26262 ASAM ISO 14229
Production Ready MBD
Testing Frugal drivers
R 4.x CT Specs drivers
Engineering eNOS AUTOSARECU Migration MCD3 API Bootloader Production Ready
PDU Router ASAM
DIAGNOSTICS MBD
Gateway
porting
ECU Specifications eNOS AUTOSAR hardware Tool chain
Legacy to MBD BSW Stack
Mode Management
Validation
ODX
Training ISO 26262
Hardware ASAM
Validation VCI LIN
OSEK
Portability Migration OSEK ISO 15765 Training Configuration
Legacy to MBD CT-Spec
NETWORK MigrationValidation

MBD
Microlayer ECU hardware hardware MANAGEMENT
eNOS ECU ISO26262 HIS-MISRA Hardware Diagnostics MBD ASAM Validation Mode Management Testing CoE
Network Management CAN
Efficient
Board Support
Diagnostics Package
R 4.x
Complex

Testing
Drivers
ODX
OTX Complex Drivers
Tool chain Production Scalablility CT-Spec
ODX Gateway
FUNCTIONAL SAFETY
Customizable LIN
HIS-MISRA Consulting
Ready
VCI DoIP
Network Management ECU Risk Assessment Optimization

drivers Training
Gateway Hazard Analysis Validation
Gateway eNOS
Scalablility
CT Consulting
Diagnostics &
PC Tools Training
MBD
ODX
Remote Diagnostic ECU
R3.x
Consulting Validation
SCALABLILITY
Consulting

DoIP ASIL Decomposition

Validation
Toolchain AUTOSAR CT-Spec
ISO 14229

BSW stack
MCD3 API
Testing CoE
MBD ASAM ISO 26262 OSEK ISO 15765 Partial HIS-MISRA CT-Spec
porting Testing CoE
Complex Drivers COM Hardware Optimization
Networking
MBD Partial Networking
OTX Risk Assessment
Mode Management
BSW Stack Bootloader ASAM MBD
Migration
porting ASAM ARTOP Training ECU eNOS
Gateway
VCI R4.x Partial Networking Tool Aftertreatment
Optimization
Microlayer Consulting FUNCTIONAL SAFETY Scalablility
Efficient ECU
BSW Stack Tool Qualification ARTOP DIAGNOSTICS hardware VCI ASIL Decomposition
DoIP ASIL A, B, C, D MCAL Risk Assessment OSEK MBD ASAM
ASAM CT-Spec
Migration Migration DoIP Customizable Qualification
AUTOSAR ECU LIN DoIP Hazard Analysis
Powerseat Mode ODX
Validation
ECU
FUNCTIONAL SAFETY
RTE generation Error handling
drivers eNOS
Management ECU Risk Assessment COM Bootloader ISO 26262
CT-Spec
MBD
ECU AUTOSAR Consulting Validation
ODX
OSEK
AUTOSAR PDU Router
Production Ready MCAL ISO 15765 CT-Spec
ISO 15765 Power Window Bootloader Network Management Validation
Development COM
porting MCD3 API
Scalablility MCD3 API
Training Tool Qualification CAN Error handling ASAM

ISO 15765
LIN R4.x ODX
HIS-MISRA
FUNCTIONAL
CT-Spec Production Ready
Portability Configuration
Validation
ODX
Gateway
ISO 14229
SAFETY LIN
OSEK Scalability ODX
MBD
Gateway ASIL Decomposition
ISO 14229
ARTOP DoIP
CAN
Bootloader LIN CAN

AUTOSAR Handbook © KPIT Technologies Ltd.

 AUTOSAR Solutions

A Premium Member of AUTOSAR consortium since 2005, KPIT provides products and
services for the various layers of AUTOSAR stack for OEMs, Tier1s, and Semiconductor
ODMs (Original Design Manufacturers). Actively involved in the automotive standardization
across the globe, we help customers at every stage of their AUTOSAR development through
end-to-end AUTOSAR Tool chain in association with leading industry Tool Suppliers.

AUTOSAR Handbook [ II ] © KPIT Technologies Ltd.

 Contents

Part 1 Introduction to AUTOSAR 01 Part 7 Functional Safety 45

1.1 AUTOSAR 02 7.1 Introduction 46
1.2 AUTOSAR Layer Model 04 7.2 AUTOSAR Architecture & Safety 47
1.3 Design and Communication of 06 Implementation in R4.0
Software Components Part 8 ECU Spectrum Toolchain 53
1.4 AUTOSAR Method 08 8.1 Introduction 54
1.5 AUTOSAR Interfaces 09 8.2 Inputs used 55
1.6 AUTOSAR Basic software Module 10 8.3 Outputs Generated 55
Part 2 Description of AUTOSAR work 11 8.4 ECU Spectrum Features 60
process and activities 8.5 Terms used 61
Part 3 Description of AUTOSAR Basic 17 Part 9 About KPIT 63
Software Module (BSW) 9.1 KPIT AUTOSAR Expertise 64
Part 4 AUTOSAR System Services 27 9.2 KPIT Advantages 65
4.1 AUTOSAR OS 28 9.3 Software Services / Products 67
Part 5 MCAL Solutions 33 Provided by KPIT
Part 6 Multicore Support 41
6.1 Introduction 42

AUTOSAR Handbook [ III ] © KPIT Technologies Ltd.

 Part 1
Introduction to AUTOSAR

AUTOSAR Handbook 1 © KPIT Technologies Ltd.

 AUTOSAR

Automotive Industry coping up with increasing complexity

The in-vehicle systems are becoming more and more complex day in and day out. Today’s hardware
and component-driven development process is becoming more and more requirement and
functional-driven. Future engineering does not aim at optimizing single components but optimizing
on system level which requires an open architecture as well as scalable and exchangeable software
modules.

AUTOSAR (AUTomotive Open System ARchitecture), a worldwide consortium of OEMs, suppliers and
other companies, founded in 2003, have been working on the development and introduction of an
open and standardized software architecture for the automotive industry.

To reduce development effort and improve quality are important reasons for introducing a uniform
procedure independent of system platform. Hardware and software are decoupled from one another
to assure such results.

The AUTOSAR concept is based on modular components with defined interfaces.

AUTOSAR Handbook 2 © KPIT Technologies Ltd.

 Application Actuator Sensor Application
Software
Component
Software
Component
Software
Component
AUTOSAR Software
Component

AUTOSAR AUTOSAR AUTOSAR

Software AUTOSAR

AUTOSAR
Interface Interface
..............
Interface Interface

Software
Component AUTOSAR Runtime Environment (RTE)
Interface
Standardized
Standardized Standardized AUTOSAR AUTOSAR
AUTOSAR
Standard
Interface Interface Interface Interface
Interface
Software
ECU
Services Communication
Abstraction
Interfaces:
Standardized Standardized Standardized
VFB & RTE
Interface Interface Interface
Standardized
relevant
Interface

Complex
RTE Operating
Device
relevant System
Standardized Drivers
BSW Interface
relevant
Possible interfaces Basic Software Microcontroller
inside Abstraction
Basic Software
(which are
not specified
within AUTOSAR) ECU-Hardware
Figure 1: Simplified Component View

AUTOSAR Handbook 3 © KPIT Technologies Ltd.

 AUTOSAR Layer Model

In AUTOSAR, the ECU software is abstracted and sub-classified as software (BSW) layer, runtime
environment (RTE) and application layer.

The Microcontroller Abstraction Layer contains internal drivers, which are software modules with
direct access to the micro controller and internal peripherals.

The ECU Abstraction Layer offers uniform access to all features of an ECU like communication,
memory or I/O, no matter if these features are part of the microcontroller or realized by peripheral
components. The drivers for such external peripheral components reside in this layer.

The Service Layer provides various types of background services such as vehicle network
communication and management services, diagnostic services, memory management, ECU state
management, mode management and Logical and temporal program flow monitoring. The operating
system is also part of this layer.

The RTE integrates the application layer with the BSW. It implements the data exchange and controls
the integration between the application software component (SWCs) and BSW.

The Application Layer contains the SWCs, which realize the application functionality of the ECU.

AUTOSAR Handbook 4 © KPIT Technologies Ltd.

 APPLICATION LAYER

RUN TIME ENVIRONMENT

SERVICES
LAYER
COMPLEX
ECU ABSTRACTION LAYER
DRIVERS
MICROCONTROLLER ABSTRACTION
LAYER

MICROCONTROLLER
Figure 2: AUTOSAR Layered Architecture

AUTOSAR Handbook 5 © KPIT Technologies Ltd.

 Design and Communication of software Components

A fundamental design concept of AUTOSAR is the separation between Application and Infrastructure.
An application in AUTOSAR consists of interconnected "AUTOSAR Software Components". The
interfaces of each SWC are formally defined. Communication between SWCs takes place chiefly over
two kinds of ports, Client/ Server ports where server is a provider of a service and the client is a user of
a service and Sender/ Receiver ports where a sender distributes information to one or several
receivers in synchronous as well as asynchronous environment. The implementation architecture of
SWC is formally defined in terms of so-called runnable entities. They correspond to procedures and are
executed on a specific event such as a periodic activation or reception of new input value. During
system design phase the SWCs can be integrated with their environment (e.g. hardware, driver, OS, etc)
based on Virtual Functional Bus (VFB). The virtual functional bus is the abstraction of the AUTOSAR
Software Components interconnections of the entire vehicle.

Once the system of SWCs is deployed to the concrete vehicle network architecture, the RTE and BSW of
involved ECUs realize the communication between the SWC either as ECU-local communication or as
network based communication.

AUTOSAR Handbook 6 © KPIT Technologies Ltd.

 SWC_ECU1 is mapped to ECU1 SWC_ECU2 is mapped to ECU2

SWC-ECU1 SWC-ECU2

Virtual Functional Bus

Sensor

Configure software components based on

communication requirements

AUTOSAR ECU1 AUTOSAR ECU2

SWC - ECU1 SWC - ECU2

Sensor Network Path

Figure 3: AUTOSAR System Design

AUTOSAR Handbook 7 © KPIT Technologies Ltd.

 AUTOSAR Method

The AUTOSAR Methods (in AUTOSAR specifications also called “Methodology”) describes the
workflow that could be followed – from the system configuration up to the final generation of an
executable for a concrete ECU.

The activities are supported by dedicated AUTOSAR tools.

For exchanging work products between such tools AUTOSAR defined one comprehensive XML file
format.

The detailed description of AUTOSAR work flow please refer Part 2 Description of AUTOSAR work prod
& activates of this handbook.

AUTOSAR Handbook 8 © KPIT Technologies Ltd.

 AUTOSAR Interfaces

AUTOSAR Interfaces are used in defining the ports of software-components and/or BSW modules.
Through these ports, software-components and/or BSW modules can communicate with each other
(Send or receive information or invoke services). AUTOSAR makes it possible to implement this
communication between Software-Components and/or BSW modules either locally or via a network.
(Refer figure 1, page 3 of handbook)

The AUTOSAR Interface is a generic interface which is derived from the ports of a SWC.
AUTOSAR Interfaces are provided by the RTE and serve as interface between SWCs or between
SWCs or between a SWC and the ECU firmware (IO HW and Complex Drivers). Via these
interfaces, a SWC an e.g. read an input value or write an output value.

The Standardized AUTOSAR Interface is a particular AUTOSAR Interface, which is already

predefined by the AUTOSAR standard. Such interfaces are used by the SWCs to access
AUTOSAR Services, which are provided by BSW modules of the Service Layer like the ECU
manager or the diagnostic event manager.
The Standardized Interface is an interface, which is predefined by the AUTOSAR standard as
API in C language. It is used between BSW module within an ECU, between RTE and Operating
System (OS), or between RTE and the Communication Layer.

AUTOSAR Handbook 9 © KPIT Technologies Ltd.

 AUTOSAR Basic Software Module

AUTOSAR has defined a set of BSW modules. They are responsible for different tasks:
Operating System
Access to non volatile memory
Communication via CAN, LIN, FlexRay and Ethernet
Handling the diagnostics
Access to I/O ports
System services like ECU state management
In addition, so-called Complex Device Drivers can be integrated into an AUTOSAR ECU. They are used
to access the features of the ECU, which are not covered by the standard BSW of AUTOSAR.

The detailed description of the BSW module parameters is included in a module specific XML file – the
BSW Module Description (compare to Figure 4 and the table in part 2 of this handbook).

A list of all BSW modules and a short description can be found in the part 3 of this handbook.

AUTOSAR Handbook 10 © KPIT Technologies Ltd.

 Part 2
Description of AUTOSAR
work products & activities

AUTOSAR Handbook 11 © KPIT Technologies Ltd.

 System per ECU

API Generator Component API SWC Implementation

SWC
System ECU RTE
Description
Configuration Configuration Generator
Description Description

RTE Extract
ECU OS, COM
ECU System ECU extract of
Configuration Generator
Description Configuration System
Generator OS Extract
(HW only) Generator Configuration

BSW
BSW module Generator
ECU extract of Extract
System System
Constraint Configuration SWC
Description Implementation MCAL
List Generator

Information/Database (no files)

Generation Step: complex algorithm or engineering work

Figure 4: Overview of the AUTOSAR method

AUTOSAR Handbook 12 © KPIT Technologies Ltd.

 Information/
Description
activities
These are constraints, which must be considered during system configuration. An
example for such System Constraints is a given (partial) communication matrix
System Constraint
from the last vehicle series, which must not be changed when designing the new
vehicle series.

This activity creates a complete System Description with the necessary SWC
Description and the associated system Communication Matrix. Basis for this
System
activity are the System Constraints. In addition, this activity requires design
Configuration decisions to be made at system level by considering the available ECU and network
Generator resources. This includes the definition of network topology, definition of SWC,
mapping of SWC to ECUs and specification of the network communication.

This includes all system information and the information that must be agreed
System
between different ECUs including the network topology and the allocation of the
Configuration
components to the ECUs. A System Description is always completed by the
Description necessary SWC Descriptions and an associated System Communication Matrix.

SWC Description This specifies information about an SWC including its ports and runnable entities.

AUTOSAR Handbook 13 © KPIT Technologies Ltd.

 Information/
Description
activities
This work product contains information from the System Configuration
ECU Extract of
Description needed for a specific ECU. It includes the description of the SWCs on
System
this ECU as well as the subset of the communication matrix relevant for the ECU.
Configuration

This creates an ECU Configuration Description. Basis is the ECU Extract and the
vendor specific BSW Module Description. In addition, this activity requires design
ECU
decisions to be made at ECU level.
configuration
Generator This includes setting values for the configurable parameters of all BSW modules
and the RTE, like mapping runnable entities to operating system tasks, defining
the memory layout or configuring the operating system.
ECU This describes all information that is local to a specific ECU the runnable software
Configuration can be built from this information and the code of the software component
Description

This activity generates the configurable part of the BSW module of an ECU. Basis
BSW
for this generation process is the ECU configuration Description of the ECU. This
Generator
activity requires no design decisions.

AUTOSAR Handbook 14 © KPIT Technologies Ltd.

 Information/
Description
activities
This describes of all configuration parameters of a particular BSW module,
BSW extract of ECU including vendor specific parameters. This description always reflects a concrete
configuration implementation of the BSW module. Therefore, it is provided by the BSW module
supplier and is not changed during the ECU configuration process.

RTE Generator This activity generates the RTE of an ECU. This activity requires no design decisions.

AUTOSAR Handbook 15 © KPIT Technologies Ltd.

 [ THIS PAGE INTENTIONALLY LEFT BLANK ]

AUTOSAR Handbook 16 © KPIT Technologies Ltd.

 Part 3
Description of AUTOSAR
Basic Software Module (BSW)

AUTOSAR Handbook 17 © KPIT Technologies Ltd.

 AUTOSAR ECU
APPLICATION LAYER

RUN TIME ENVIRONMENT

SERVICE
LAYER
COMPLEX
ECU ABSTRACTION LAYER
DRIVERS
MICROCONTROLLER ABSTRACTION
LAYER

MICROCONTROLLER

SERVICES PRODUCTS

Figure 5: AUTOSAR Stack and KPIT Offerings

AUTOSAR Handbook 18 © KPIT Technologies Ltd.

 APPLICATION LAYER

RUN TIME ENVIRONMENT

IPDU MULTIPLEXER

INTERFACE
WATCHDOG MGR
INHIBITION MGR

AUTOSAR
SYNC TIME BASE

GEN. NM
COM MANAGER
ECU STATE MGR

ERROR TRACER
DEVELOPMENT

CAN/ LIN/FR STATE

DCM
COM
DIAGNOSTIC
EVENT MGR
FUNCTION

MANAGER
MGR
NVRAM MANAGER I/O SIGNAL INTERFACE
PDU ROUTER
CAN/
CAN/ FR LIN/
TRANSPORT FR NM
DIAGNOSTIC LOG

MEMORY ABS INTERFACE CAN/LIN/FLEXRAY/ETHE

AND TRACE

WATCHDOG INTERFACE RNET INTERFACE

EEPROM FLASH DRIVER FOR DRIVER FOR
ABSTRACTION EEPROM CAN/FR/ETH EXT. EXT. COMPLEX
EMULATION DRIVER FOR ADC ASIC I/O ASIC
EXTERNAL TRANS-
EXTERNAL DRIVERS
AUTOSAR OS

EEPROM EXT FLASH CEIVER

CAN ASIC
DRIVER DRIVER DRIVER
BASIC SOFTWARE
MODULE MGR

MCU MEMORY COM I/O

DRIVERS DRIVERS DRIVERS DRIVERS

MICROCONTROLLER

Figure 6: BSW Modules (Not all modules are shown)

AUTOSAR Handbook 19 © KPIT Technologies Ltd.

 Module Name Description

The CAN Interface provides hardware independent access mechanisms for the
CAN Interface ECU’s CAN channels (on chip or on board). It controls the CAN driver as well as the
transceiver driver, and forms an interface to the high level modules.
The CAN Network Management is responsible for a coordinated transmission
CAN Network
between the wake-up and sleep states within a CAN network. An additional
Management
function delivers a list of all ECUs available on the bus.
The CAN State Manager handles bus specific errors as well as the activation and
CAN State Manager deactivation of the PDU groups.

The CAN Transport Protocol conforms to ISO standard 15765-2 TPL and manages
segmenting of data in the transmit direction, assembling of data in the receive
CAN Transport Layer direction, and monitoring of the data stream. Error detection such as message loss,
duplication and sequence errors are also handled by the module.

The driver is responsible for controlling the operating state of an external CAN
CAN Transceiver
transceiver. Also responsible for Network diagnostics and control of wake up and
Driver
sleep functions.

AUTOSAR Handbook 20 © KPIT Technologies Ltd.

 Module Name Description

The FlexRay interface provides identical access mechanisms for the ECUs FlexRay
FlexRay Interface channels, independent of their implementation (microcontroller internal or
external). It extracts the number of FlexRay drivers and manages the
synchronization to global FlexRay time.
This module is responsible for the FlexRay network management. It coordinates
FlexRay Network
the transition between normal operation and bus-sleep mode of the network.
Management

FlexRay State The FlexRay State Manager controls and monitors the wakeup and startup of the
Manager node in the FlexRay cluster.

The FlexRay transport protocol segments long data packets in the transmit
FlexRay Transport direction, collects data in the receive direction and controls the data flow. Errors
Layer such as message loss, message duplication or sequencing errors are detected.

FlexRay Transceiver The driver for an external FlexRay transceiver is responsible for Network
Driver diagnostics and switching a transceiver on and off.

AUTOSAR Handbook 21 © KPIT Technologies Ltd.

 Module Name Description

The LIN Interface provides a hardware independent interface for access to LIN
LIN Interface frames. In addition, it manages Schedule Table processing and the implementation
of the LIN Transport Layer and LIN Network Management.
LIN Network This module is responsible for the LIN network management. It coordinates the
Management transition between normal operation and bus-sleep mode of the network.

The LIN State Manager switches the Scheduler Tables as well as the PDU groups in
LIN state Manager COM and servers the LIN Interface in term of sleep and wake-up. In addition it
manages the activation of the LIN Transceiver driver.
The LIN transport protocol segment data in the transmit direction, collects data in
the receive direction and controls the data flow. Errors such as message loss,
LIN Transport Layer message duplication or sequencing errors are detected. The LINTP is part of the
LINIF.
LIN Transceiver The LINTRCV driver for an external LIN transceiver is responsible for monitoring
Driver and controlling the wake-up and sleep functions.

AUTOSAR Handbook 22 © KPIT Technologies Ltd.

 Module Name Description

This module provides to upper layers a hardware independent interface to the

Ethernet Communication System comprising multiple different Ethernet
Ethernet Interface controllers and transceivers. This interface is uniform for all Ethernet controllers
and transceivers. Thus, the upper layers (Internet Protocol, Address Resolution
Protocol) may access the underlying bus system in a uniform manner.
The module provides to the upper layer (Ethernet Interface) a hardware
independent interface comprising multiple equal transceivers. This interface is
Ethernet Transceiver uniform for all transceivers. Thus, the upper layer (Ethernet Interface) may access
Driver the underlying bus system in a uniform manner. The configuration of the Ethernet
Transceiver Driver however is bus specific, since it takes into account the specific
features of the communication transceiver.
The Ethernet State Manager shall provide an abstract interface to the AUTOSAR
Ethernet State Communication Manager to startup or shutdown the communication on an
Manager Ethernet cluster. It does not directly access the Ethernet hardware

AUTOSAR Handbook 23 © KPIT Technologies Ltd.

 Module Name Description

The NM module provides a general, network independent interface for access to

Generic Network bus-dependent network management modules (CANNM and FRNM). In addition,
Management Interface the module manages the synchronous, cross-network shutdown of the
communication system in conjunction with the other ECUs.
The communication layer provides a signal-based data interface for the
application, and sends messages according to the defined send types. Additional
Communication interfaces are provided in the form of messaging mechanisms for successful
Manager sending and receiving of data as well as their timeouts. For multi-channel ECUs, the
module COM also provides an option to route signals between communication
buses (signal gateway)

This module implements diagnostic communication as per ISO14229-1 (UDS).

Diagnostic Diagnostic requests are partially converted directly in DCM (administration of
Communication diagnostic sessions, reading error codes, EcuReset,…), and partially sent to
Manager software components via port interfaces (reading, writing, and controlling of data
identifiers, execution of routines, …).

AUTOSAR Handbook 24 © KPIT Technologies Ltd.

 Module Name Description

IPDU Multiplexer This module deals with multiple uses of fixed PDUs with different data contents.

The EA module provides a hardware independent interface for access to EEPROM

driver (EEP). Data blocks can be read, written, or deleted. In addition, the EA
EEPROM Abstraction
module distributes write request across different areas of the EEPROM so that all
EEPROM cells are subjected to equal load, and their lifespan is increased.

The FEE module provides a hardware independent interface for access to flash
Flash EEPROM data using a flash driver (FLS). Data blocks can be read, written, or deleted. In
Emulation addition, the FEE module distributes write requests across different areas of the
flash so that all flash cells are to equal load, and their lifespan is increased.

This module allows the NVRAM manager to access several memory abstraction
Memory Abstraction modules (FEE or EA modules). This module abstract from the number of underlying
Interface FEE or EA modules and provide upper layers with a virtual segmentation on a
uniform linear address space.

AUTOSAR Handbook 25 © KPIT Technologies Ltd.

 Module Name Description

On request, We offer the implementation of drivers for externally connected

External Driver components as an extension to AUTOSAR 3.0. These are already available for the
control of certain EEPROM (EEPEXT), flash components (FLSEXT), Watchdog
(WDGEXT), … for example

This module provides uniform access to services of the watchdog driver (WDG),
Watchdog Interface
such as mode switching and triggering.

The Watchdog Manager monitors the reliability and functional assurance of the
application in an ECU. This includes monitoring the correct execution of the SWCs
and BSW modules, and the triggering of Watchdog at the required time intervals. It
Watchdog Manager
reacts to possible faulty behavior on numerous escalation levels. Where
resumption of normal operation is impossible, the Watchdog hardware performs a
reset of the microcontroller.
The I/O Hardware Abstraction represents the connection between the RTE and the
I/O Hardware
I/O channels of the ECU. It encapsulates access to the I/O drivers such as ADC, DIO
Abstraction
or PWM, thereby making available the ECU’s I/O signals.

AUTOSAR Handbook 26 © KPIT Technologies Ltd.

 Part 4
AUTOSAR System Services

AUTOSAR Handbook 27 © KPIT Technologies Ltd.

 AUTOSAR OS

This module is the operating system of an AUTOSAR ECU. It is actually an

extended OSEK operating System. The extensions are organized so-called
scalability classes (SC1-SC4). They cover the following features.
Sc1 : deterministic RTOS baseline (tasks, events, counters, alarms, messages)
SC2 : timing based task determinism (low-latency, precise timing for periodic tasks)
Sc3 : protected memory (MMU/MPU) for tasks avoids memory collisions for safety
SC4 : timing and memory protected tasks, utilizes the full capabilities of the silicon for secure &
protected Automotive grade RTOS

AUTOSAR Handbook 28 © KPIT Technologies Ltd.

 SC1 SC2 SC3 SC4 Hardware Requirements

OSEK OS (All Conformance Classes)

Counter Interface

Schedule Tables

Stack Monitoring

ProtectionHook

Timing Protection Timers with high priority interrupt

Global Time/Synchronization Support Global Time Source

Memory Protection MPU

OS-Application

Service Protection

CallTrustedFuction (non-) privilege Modes

Figure 7: Scalability Class Details

AUTOSAR Handbook 29 © KPIT Technologies Ltd.

 WATCHDOG MGR
INHIBITION MGR

SYNC TIME BASE

COM MANAGER
ECU STATE MGR

ERROR TRACER
DEVELOPMENT
DIAGNOSTIC
EVENT MGR
FUNCTION

MGR
DIAGNOSTIC LOG
AND TRACE

APPLICATION LAYER

RUN TIME ENVIRONMENT

AUTOSAR OS

BASIC SOFTWARE

OPERTING SYSTEM & MEMORY COM

MODULE MGR

SYSTEM SERVICES SERVICES SERVICES

I/O
HW
ONBOARD MEMORY COM ABSTRACTION
COMPLEX
DEVICE HARDWARE HARDWARE
ABSTRACTION DRIVERS
ABSTRACTION ABSTRACTION

MCU MEMORY COM I/O

DRIVERS DRIVERS DRIVERS DRIVERS

MICROCONTROLLER

Figure 8: System Services

AUTOSAR Handbook 30 © KPIT Technologies Ltd.

 Module Name Description

The ECU State Manager performs the initialization/de-initialization of all basic

ECU State Manager software modules, including the RTE and the operating system (OS). The module
controls the operating state of an ECU (Sleep, Startup, Wakeup, Shutdown, and
Run) based on system events.

This module controls the state of all communication channels connected to the
Communication
ECU and provides a bus-independent interface to the SWCs (and thereby their
Manager application) for requesting external communication.

This module controls (enable/disable) functionalities of SW components based on

Function Inhibition the conditions such as faults, signal quality, ECU and vehicle states, diagnostic
Manager tester commands, etc.

This module implements error memory as per manufacturer-specific

Diagnostic Event documentation. A standardized interface for diagnostic monitors allow for
uniform, cross-manufacturer development of software components. The DEMs
Manager
module is responsible for administrating the Diagnostic TroubleCode statuses, the
error environment data, and for storing the data in NVRAM.

AUTOSAR Handbook 31 © KPIT Technologies Ltd.

 Module Name Description

This module supports error searches during software development and provides
Development Error
an interface for error reporting. This interface is called from the individual BSW
Tracer modules in an error situation.
The SCHM module calls the cyclic function for the individual BSW modules and
makes available the functions that the BSW modules need to call at the beginning
BSW Scheduler
and end of critical sections. This Module is part of RTE (Runtime Environment in
R4.0)
The Cyclic Redundancy Check module provides a service function for computing
CRC Routines
CRC checksum.
Runtime The RTE is responsible for the execution of the software components and realize
Environment the data exchange between the software components and the basic software.

AUTOSAR Handbook 32 © KPIT Technologies Ltd.

 Part 5
MCAL Solutions

AUTOSAR Handbook 33 © KPIT Technologies Ltd.

 APPLICATION LAYER

RUN TIME ENVIRONMENT

OPERTING SYSTEM & MEMORY COM

SYSTEM SERVICES SERVICES SERVICES
I/O
HW
MEMORY COM ABSTRACTION
ONBOARD DEVICE COMPLEX
HARDWARE HARDWARE
ABSTRACTION
ABSTRACTION ABSTRACTION DRIVERS

FLEXRAY DRIVER
INTERNAL FLASH

EPROM DRIVER

SPI HANDLER

PWM DRIVER

PORT DRIVER
MCU DRIVER
GPT DRIVER

ADC DRIVER
WATCHDOG

FLASH TEST

DIO DRIVER
ICU DRIVER
ETHERNET
CORE TEST

RAM TEST

DRIVER

DRIVER

DRIVER

DRIVER
DRIVER

DRIVER

CAN

LIN
LIN OR
FLASH
POWER

CLOCK

PWM
WDT

CAN
UNIT

ADC
EXT.
MCU
GPT

DIO
BUS

CCU
SPI

SCI
&

MICROCONTROLLER

Figure 9: ECU spectrum MCAL Modules

AUTOSAR Handbook 34 © KPIT Technologies Ltd.

 Module Name Description

Port Driver This module provides service for initialize the entire port structure of the
microcontroller.
The Digital Input Output Driver provides read and write services to the DIO
DIO Driver
channels (pins), DIO port and DIO channel groups.
The ADC Driver is responsible for controlling the analog to digital converter and
for accessing the results of a conversion. In detail, it initializes the converter,
ADC Driver provides services for starting or ending a conversion, and for selecting the trigger
source and for selecting the trigger source and trigger condition.

The Pulse Width Modulation Driver provides services for initialization and
PWM Driver
controlling PWM channels of the microcontroller
The ICU driver provides services for edge detection, measuring periodic signals,
ICU Driver
assigning edge timestamp and controlling wake-up interrupts.

AUTOSAR Handbook 35 © KPIT Technologies Ltd.

 Module Name Description

The CAN driver provides services for initializing the CAN controller, for sending
CAN Driver and receiving messages, and for switching the controller states (sleep, stop etc.).

The FlexRay Driver is used to abstract hardware related differences between

different FlexRay communication controllers. All the necessary properties of the
FlexRay Driver
communication controller per the FlexRay Protocol Specification are encapsulated
in this module and can be reached via its uniform interface.

The LIN Driver provides services for initiating frame transmission (Header,
LIN Driver Response, Sleep Mode and Wake-Up) as well as receiving responses, checking the
momentary state and validating wake-up events.

SPI Handler / Driver The SPI driver provides an option for exchanging data across the SPI interface. It is
primarily used for external connection of EEPROM and Watchdog, …
The Ethernet driver provides an option for data exchanges over Ethernet interface.
Ethernet Driver With the Ethernet interfacing available in, it is possible to develop very powerful
gateways with a MOST connection and thereby utilize the advantages of the
AUTOSAR architecture.

AUTOSAR Handbook 36 © KPIT Technologies Ltd.

 Module Name Description

The EEPROM driver enables hardware independent, uniform access to EEPROM

EEPROM Driver storage. It makes available services for reading, writing, and data comparison, as
well as for deleting blocks.
The flash driver provides a hardware independent and uniform access to flash
Internal Flash Driver memory. It offers services for reading, writing and comparing of data and the
erasure of blocks (sector).

This module tests microcontroller internal RAM cells. A complete test is performed
RAM Test during startup and shutdown of the ECU, or is trigged by a diagnostic command. A
cyclical test (block for block or cell for cell) is performed during normal operation.

AUTOSAR Handbook 37 © KPIT Technologies Ltd.

 Module Name Description

This module provides services to control and trigger watchdog hardware. The
Watchdog Driver
trigger routine is called by the watchdog manager.

The General Purpose Timer Driver provides an interface for access to the
GPT Driver microcontroller’s internal timers. It can be used to control events that occur
periodically or once-off.

The Micro Controller Unit Driver provides the following services:

Software-triggered microcontroller reset.
Selection of the microcontroller power mode (STOP, SLEEP, HALT, etc.)
MCU Driver
Configuration of wake-up behavior.
Management of the internal PLL clock unit.
Initialization of RAM areas with pre-defined values.

The Core Test Driver provides services for configuring, starting, polling,
terminating and notifying the application about Core Test results. It also provides
Core Test services for returning test results in a predefined way. Furthermore it provides
several tests to verify dedicated core functionality like e.g. general purpose
registers or Arithmetical and Logical Unit (ALU).

AUTOSAR Handbook 38 © KPIT Technologies Ltd.

 Module Name Description

The Complex Drivers contain drivers which are not standardized in AUTOSAR and
which utilize specific properties of a microcontroller or ECU (e.g. complex
Complex Drivers
peripheral devices). They include functionalities for sensor evaluation and
controller monitoring with direct access to the microcontroller.

AUTOSAR Handbook 39 © KPIT Technologies Ltd.

 [ THIS PAGE INTENTIONALLY LEFT BLANK ]

AUTOSAR Handbook 40 © KPIT Technologies Ltd.

 Part 6
Multicore Support

AUTOSAR Handbook 41 © KPIT Technologies Ltd.

 Introduction:

As the demand for computing power is rapidly increasing in the automotive domain, OEMs and
Tier-one suppliers are gradually introducing multicore ECUs in their electronic architectures.
Additionally, these multicore ECUs offer new features such as higher levels of parallelism which ease
the respect of the safety requirements such as the ISO26262 and the implementation of other more
complex automotive use-cases. Main use cases for multicore ECUs can be;
1. Decreasing complexity of architecture
2. Dealing with resource demanding applications
3. Improving the safety
4. Dedicated use of cores
Keeping all this in mind, AUTOSAR version 4.0 has introduced support for multi-core embedded real-
time operating systems. New concepts such as locatable entities (LEs), multi-core startup/shutdown,
Inter-OS-Application Communicator (IOC), and Spinlock have been introduced in the AUTOSAR multi-
core OS architecture specification to extend the single-core OS specifications.
The Inter-OS-Application Communicator (IOC) which is part of AUTOSAR OS, provides
communication services which can be accessed by clients which need to communicate across OS-
Application boundaries on the same ECU. Every Core runs a kind of ECU state management. Each core
will also have 'Core Test' module running in BSW.

AUTOSAR Handbook 42 © KPIT Technologies Ltd.

 ECU
Core0 Core1

APPLICATION LAYER

RUN TIME ENVIRONMENT

ECU State
OPERTING SYSTEM &
Manager MEMORY COM
SYSTEM SERVICES SERVICES SERVICES
I/O SYSTEM SERVICES
HW ECU State
ONBOARD MEMORY COM ABSTRACTION Manager
ASR OS

COMPLEX
DEVICE HARDWARE HARDWARE
ABSTRACTION DRIVERS
ABSTRACTION ABSTRACTION

ASR OS
COMPLEX
MCU MEMORY COM I/O DRIVERS
IOC

DRIVERS DRIVERS DRIVERS DRIVERS

IOC
MICROCONTROLLER

Figure 10: An ECU with two core microcontroller

AUTOSAR Handbook 43 © KPIT Technologies Ltd.

 [ THIS PAGE INTENTIONALLY LEFT BLANK ]

AUTOSAR Handbook 44 © KPIT Technologies Ltd.

 Part 7
Functional Safety

AUTOSAR Handbook 45 © KPIT Technologies Ltd.

 Introduction:

Functional Safety is part of the overall safety of a system that depends on the correct execution of
specific functions. The goal of functional safety is to perform the intended function correctly or the
system will fail in a predictable safe manner. Functional safety standard ISO26262 which is derived
from IEC-61508 mandates us to have automotive specific risk based approach for Electrical and
Electronic (E/E) systems. It is applicable to passenger cars with max gross weight up to 3.5 tons.

Aspects such as complexity of the system design can be relevant for achievement of functional safety
in automotive field. Software is one parameter that can influence complexity on system level. New
techniques and concepts for software development can be used in order to minimize complexity and
therefore can ease the achievement of functional safety.
As a software standardization initiative, AUTOSAR R4.0 considers aspects of functional safety relevant
for today’s automotive software development.

AUTOSAR Handbook 46 © KPIT Technologies Ltd.

 AUTOSAR Architecture & Safety Implementation in R4.0:

Memory Protection feature (MPU) in OS – “SC4”

Multi core OS features
E-Gas monitoring related features
Program flow monitoring related features
Timing related features includes;
Features related to the provision of synchronized time bases
Provision of a synchronized time-base within a cluster
Services for accessing to synchronized time-bases
Sync AUTOSAR OS with FlexRay Global Time in a well-defined way
Features related to synchronization of processing of asynchronous processing units
Services for synchronization of SW-Cs
Features to allow time deterministic implementation of applications
Features related to protection against timing violation
Program flow monitoring related features
Communication Stack Related Features such as Data sequence control and multiple communication
links
SWC End-to-End (E2E) communication protection
Memory partitioning and user/supervisor-modes Related Features

AUTOSAR Handbook 47 © KPIT Technologies Ltd.

 Libraries
OS-Application 2 OS-Application 1

Receiver 1 Sender
E2E protection E2E protection
wrapper wrapper

HW
SW
RUN TIME ENVIRONMENT

COMPLEX
OPERATING SYSTEM & MEMORY COM
E2E Library

SW DRIVERS
SW SYSTEM SERVICES SERVICES SERVICES
I/O
HW
IOC ONBOARD MEMORY COM ABSTRACTION

RTE Wrapper
Receiver 2
DEVICE HARDWARESW HARDWARE
ABSTRACTION ABSTRACTION ABSTRACTION

MCU MEMORY COM I/O

DRIVERS DRIVERS DRIVERS DRIVERS

HW HW Micro
MICROCONTROLLER 1/ ECU 1 controller 2/
ECU2

Figure 11: Safety End to End (E2E) Communication Protection Module

AUTOSAR Handbook 48 © KPIT Technologies Ltd.

 Figure 11 describes typical sources of interferences, causing errors detected by E2E protection:
SW-related sources:
Error in mostly generated RTE,
Error in partially generated and partially hand-coded COM
Error in network stack
Error in generated IOC or OS
HW-related sources:
Microcontroller error during core/partition switch
Failure of HW network
Network EMI
Microcontroller failure during context switch (partition) or on the communication between
cores
E2E Lib extends signals with CRC- and Sequence Counter-information on the sender side and checks
the information on the receiver side, ensuring efficient ‘communication failure’ detection between
SWCs.

AUTOSAR Handbook 49 © KPIT Technologies Ltd.

 Partition 2 (No ASIL) Partition 1 (ASIL D) Partition 3 (ASIL A)

Application Actuator Sensor Application

Software
Component
Software
Component
Software
Component
AUTOSAR Software
Component

AUTOSAR
Software AUTOSAR
AUTOSAR AUTOSAR
Interface
! Interface Interface
.............. Interface

AUTOSAR Runtime Environment (RTE)

Standardized
Standardized Standardized AUTOSAR AUTOSAR
AUTOSAR
Interface Interface Interface Interface
Interface
ECU
Services Communication
Abstraction
Standardized Standardized Standardized
Standardized

Interface Interface Interface

Inteface

Complex
Operating
Device
System
Drivers
Standardized
Interface
Basic Software Microcontroller
Partition 5 (ASIL D) Abstraction

ECU-Hardware
Figure 12: Partitioning concept in functional safety

AUTOSAR Handbook 50 © KPIT Technologies Ltd.

 Various software components (SW-Cs) are implemented with different Automotive Safety Integrity Levels (ASILs) in
application layer. ASIL A, ASIL B, ASIL C and ASIL D are different safety integrity levels which are followed during
software development depending on complexity and criticality of modules/ components (‘A’ being least critical, ‘D’
is most critical).
Severity of Failure

Probability of control
Probability of exposure

Exposure Controllability Severity ASIL

ASIL A ASIL D
Least stringent ASIL B ASIL C Most stringent

Figure 13: Automotive Safety Integrity Levels (ASIL)

AUTOSAR Handbook 51 © KPIT Technologies Ltd.

 With partitioning concept in AUTOSAR R4.0, SWCs can be placed into separate partitions of ECU. These partitions
can be terminated, monitored and restarted independently. The sole purpose of these separate partitions is to
achieve “Freedom from Interference”. With this SWCs with different ASILs (according to ISO26262) can be executed
on same ECU.

AUTOSAR Handbook 52 © KPIT Technologies Ltd.

 Part 8
ECU Spectrum Toolchain

AUTOSAR Handbook 53 © KPIT Technologies Ltd.

 Introduction:

KPIT’s ECU Spectrum toolchain dynamically generates GUI controls for AUTOSAR Modules specified in
ECU Configuration Parameter Definition File and also generates ECU Configuration Description File.

ECU Spectrum toolchain supports Plug-in option for Generation Tools including third party
Generation Tools. Using this feature, ‘C’ Header and Source files can be generated directly by invoking
the Generation Tool from the ECU Spectrum.

AUTOSAR Handbook 54 © KPIT Technologies Ltd.

 Inputs Used:

ECU Configuration Parameter Definition File(s): in XML format and contains definition for
Modules, Containers and Parameters. The format of the XML file must compliant to AUTOSAR ECU
specification standards.

Custom Configuration CSV file: as input at the time of loading the System Configuration Description
file. This CSV file is in text format and contains the tier-1 specific notifications and ECU Configuration
gets updated automatically based on the notifications.

Outputs Generated:
The output of ECU Spectrum software is ECU Configuration Description File in XML format, which
contains the configured values for Parameters, Containers and Modules. ECU Configuration
Description File format must compliant to AUTOSAR ECU specification standards.

AUTOSAR Handbook 55 © KPIT Technologies Ltd.

 KPIT
ECU Spectrum
• N/W Design Architecture
• Application Schema
Design

APPLICATION LAYER

RUN TIME ENVIRONMENT

KPIT KPIT
OS &
ECU Spectrum SERVICES ECU Spectrum
COMPLEX
• RTE Configuration ECU ABSTRACTION LAYER
DRIVERS
• BSW Configuration
• RTE Code Generation MICROCONTROLLER ABSTRACTION
• BSW Code Generation
LAYER

MICROCONTROLLER

KPIT
ECU Spectrum
• MCAL Configuration
• MCAL Code Generation

Figure 14: KPIT’s ECU Spectrum Toolchain for AUTOSAR Layered Model Development

AUTOSAR Handbook 56 © KPIT Technologies Ltd.

 ECU Configuration KPIT ECU Project Setting File
Parameter Definition
file (AUTOSAR XML) Spectrum (.ONE FILE)

ECU Configuration Generation

Parameter Description
file (AUTOSAR XML) Tools

Header and Source

Files (.C FILES)

Figure 15: ECU Spectrum Workflow – High-level

AUTOSAR Handbook 57 © KPIT Technologies Ltd.

 ECU Extract, DBC, Parameter Definition
FIBEX, LDF, ODX HARDWARE IN LOOP TESTING (HIL) File
CONFORMANCE TEST EXPERIENCE
APPLICATION MIGRATION
OEM/ Tier1 Software
Component OS CONFIGURATION & GENERATOR
Application
Description
APPLICATION MCAL
SOFTWARE CONFIGURATION
AUTOSAR DESIGN & VALIDATION
SCHEMA BSW MCAL
RTE COMPLEX
BASED CONFIGURATION & MANAGEMENT
APPLICATION
CONFIGURATION RTE/ BSWDRIVERSBSW/ MCAL CONSOLE
VALIDATION
DESIGN ECU ECU
ECU
Application RTE BSW
Configuration Configuration
Hardware
Description Description
NETWORK RTE File SYSTEM File BSW NEUTRAL
DESIGN/ CODE CODE MCAL
ARCHITECTURE GENERATION SERVICES
GENERATION TESTING
APPLICATION MCAL
CODE CODE
GENERATION GENERATION

RTE C Source & Header

C Source & Header File
File
Compiler/ BSW
Linker Static Code
BSW/MCAL Module C
Application Header File
Source & Header File

Figure 16: ECU Spectrum Workflow – Detailed

AUTOSAR Handbook 58 © KPIT Technologies Ltd.

 Menu Bar Toolbar

Left Selection View Message Info Area Right Configuration View

Figure 17: ECU Spectrum Main Screen

AUTOSAR Handbook 59 © KPIT Technologies Ltd.

 ECU Spectrum Features

Simple to use like any other Windows based tool

User-friendly GUI
Support for MRU (Most Recently Used) feature
Validation - The module’s configuration can be checked for correctness and completeness
through validation.
For any inconsistencies/dependencies, the Editor displays the Error(s) / Information(s) /
Message(s) in the ’Message Info’ window
Storing and Loading of User Configuration data
Import of AUTOSAR ECU Extract, DBC, LDF and Fibex data
HTML Report Generation - Editor allows the user to get the summary of the currently loaded
project
Microsoft compliant Help Support
Easy installation and setup
Less memory consumption
No dependency on any RTE

AUTOSAR Handbook 60 © KPIT Technologies Ltd.

 Terms Used:

Project:
A Project is used to store the configuration in “.one” file format.

Module:
Modules denote an ECU Configuration Parameters Software Module. Individual modules are assigned
a unique name. Number of module instances depends on multiplicity of the module.

Container:
Containers are used to group parameters and references. The number of instances of a container
depends on multiplicity of the container.

Sub-Container:
A Sub-Container is also used to group parameters and references. Sub-container is a part of container.
Sub-containers are defined in containers. The number of instances of a container depends on
multiplicity of the container.

AUTOSAR Handbook 61 © KPIT Technologies Ltd.

 Multiplicity:
Multiplicity is used to specify how often a specific configuration element (module, container,
parameter or reference) may occur in an ECU Configuration Description file. Lower-Multiplicity and
Upper-Multiplicity are two attributes to specify minimum and maximum occurrences. In any case
Lower-Multiplicity should be less than or equal to Upper-Multiplicity. Lower-Multiplicity is mentioned
as 1 means that the element is mandatory. Lower-Multiplicity mentioned as 0, means that the element
is an option. Upper-Multiplicity mentioned as * means that the parameter can occur any number of
times.

Multiple Configuration Set:

It is used to allow the description of several ECU Configuration Sets.

Template:
Templates are definitions of configurable elements (Module, Container or Sub-Container). This format
is taken from the Definition File.

Calculation Formula:
A Calculation formula is used to provide information about how the values can be computed. It utilizes
references to address foreign elements to gather the required information.

AUTOSAR Handbook 62 © KPIT Technologies Ltd.

 Part 9
About KPIT

AUTOSAR Handbook 63 © KPIT Technologies Ltd.

 KPIT AUTOSAR Expertise

AUTOSAR development at KPIT started in early 2005 when we became AUTOSAR Premium
Member. We are actively contributing to the standardization movement of AUTOSAR and have
been appointed as a general contractor for writing Conformance Specifications for the AUTOSAR
standard. We are also the general contractor for the AUTOSAR conformance test project.
We are an AUTOSAR software platform focus company and endorse the AUTOSAR philosophy of
“Cooperate on Standards”.
Our focus area in AUTOSAR is to develop AUTOSAR BSW Modules & MCAL drivers as part of the
AUTOSAR stack and provide services around these Modules. We have developed the first complete
MCAL product.
In our endeavor to provide standard compliant, high quality, and production ready components we
cooperate with specialized AUTOSAR tools. The expectation from the cooperation is to make our
components compatible with these specialized AUTOSAR compliant tools.
We are continuously supporting Network platforms to premium brands in Europe for last 7 years
and have supplied platforms for about 150 ECUs which are integrated in the vehicles-on-road. This
support is currently being extended to AUTOSAR.
We are also the Premium member of JasPar.

AUTOSAR Handbook 64 © KPIT Technologies Ltd.

 KPIT Advantages

Faster time to complete AUTOSAR Conformance by supplying components that are compliant to
AUTOSAR standard.
Reduced in Bill of Material (BOM) costs through the Automotive-grade BSW components.
Improved performance of platforms through Hand-coded, Optimized AUTOSAR BSW Modules
including MCAL.
Faster and full-proof AUTOSAR migration of the legacy Applications by designing Application
Migration methodologies.
Reduced in development overhead and overall Time-to-Market (TTM) by using KPIT AUTOSAR Tool
chain

AUTOSAR Handbook 65 © KPIT Technologies Ltd.

 Enabling New Executed AUTOSAR migration for safety ECU
Strong experience in migrating safety critical applications to upcoming,
Technology improved communication protocols such as FlexRay
Adoption

AUTOSAR Safety ECU created with the Tier1performs better than legacy
Unique Business Model makes the migration process more cost effective and
Optimization
smoother you will
Customer does not get Locked to specific tool, vendor product or methodology

KPIT Application Migration Methodology designed for extensibility and thus

Renovative helps you design long term AUTOSAR strategy rather than experimenting
with a pilot alone
Improvement Migration methodology helps you to reuse your legacy toolchain and
modifies them to adopt newer requirements as much as possible

Onsite + Offshore model of engagement improves speed of execution with

better efficiencies
Time Benefit
Already built and tested conformance test suites enable fastest path to
production readiness

AUTOSAR Conformance Spec experience helps you build solution that

passes conformance tests quickly
Enabling Compliance Open Test & Automation Framework invented by KPIT helps you test and
validated performance of the system at multiple levels in the V Cycle
Our Methodologies help you meet desired system performance

Figure 18: KPIT AUTOSAR Differentiation Diagram

AUTOSAR Handbook 66 © KPIT Technologies Ltd.

 Software Services / Products Provided by KPIT

HARDWARE ININ
HARDWARE LOOP TESTING
LOOP (HIL)
TESTING (HIL)

CONFORMANCE TEST
CONFORMANCE TESTEXPERIENCE
EXPERIENCE
APPLICATION
APPLICATION MIGRATION
MIGRATION

OSCONFIGURATION
OS CONFIGURATION &&GENERATOR
GENERATOR

APPLICATION
APPLICATION
MCAL
MCAL
SOFTWARE
SOFTWARE
CONFIGURATION
CONFIGURATION
AUTOSAR
AUTOSAR DESIGN
DESIGN
SCHEMA
SCHEMA RTE COMPLEX MCAL
MCAL
RTE COMPLEX BSW
BSW
BASED
BASED CONFIGURATION MANAGEMENT
MANAGEMENT
CONFIGURATION DRIVERS
DRIVERS CONFIGURATION
CONFIGURATION
APPLICATION
APPLICATION CONSOLE
CONSOLE
DESIGN
DESIGN
Application ECU
ECU
Application RTE BSW
BSW Hardware
Hardware
NETWORK
NETWORK RTE BSW
BSW NEUTRAL
NEUTRAL
CODE
CODE SYSTEM
SYSTEM
DESIGN/
DESIGN/ CODE
CODE MCAL
MCAL
SERVICES
SERVICES
ARCHITECTURE
ARCHITECTURE GENERATION
GENERATION GENERATION
GENERATION TESTING
TESTING
APPLICATION
APPLICATION MCAL
MCAL
CODE
CODE CODE
CODE
GENERATION
GENERATION GENERATION
GENERATION

RD
KPIT PRODUCT
PRODUCT KPIT SERVICE
SERVICE KPIT SERVICEUSING
USING3 3 PARTY
PARTYTOOLS
TOOLS

Figure 19: Setting up AUTOSAR environment with KPIT

AUTOSAR Handbook 67 © KPIT Technologies Ltd.

 [ THIS PAGE INTENTIONALLY LEFT BLANK ]

AUTOSAR Handbook 68 © KPIT Technologies Ltd.

 © KPIT Technologies Ltd. 2013

Legal Notice

We have made all efforts to offer current, correct and clearly-expressed information

All information in this handbook has been compiled meticulously; however, we cannot guarantee that the contents are completely accurate or free of
errors. Neither the KPIT Technologies Ltd. nor the authors of this document accept any legal responsibility for its contents or any consequences, including
direct or indirect liability, arising from its use.

KPIT Technologies Ltd. reserves the right to revise or change information contained in this document at any time without notice or justification to any
person or entity.

AUTOSAR and the AUTOSAR logo are registered trademarks of the AUTOSAR GbR. The AUTOSAR specifications are copyright protected intellectual
property and may not be used without prior permission. In case you want to use it, please contact the AUTOSAR GbR (www.autosar.org)
V 1.0-0612

AUTOSAR Handbook 69 © KPIT Technologies Ltd.

 Headquarter - India China Germany
KPIT Technologies Ltd. KPIT (Shanghai) Software In2Soft GmbH
Plot No 35/36, Technology Co. Ltd. (A KPIT Company)
Rajiv Gandhi Infotech Park, Room 504, LZY Tower, Adams-Lehmann-Str. 109
Phase 1, MIDC, 4711 Jiaotong Road, Putuo District, 80797 Munich
Hinjawadi, Pune - 411057, India Shanghai 200331, China Germany
Phone: +91 - 20 - 66525000 Tel: +86 21 56313620 Phone: +49-89-322-9966-0
Fax: +91 - 20 – 66525001 Fax: +86 21 56313925 Fax: +49-89-322-9966-999

Japan South Korea USA

KPIT Technologies Ltd. Korea Liaison Office KPIT Infosystems Inc.
Muromachi CS Bldg. 7F, 3-306 Eunma Apt. 33 Wood Avenue South,
4-6-5, Nihonbashi - Muromachi, Daechi-dong Gangnam-gu STE 720, Iselin, NJ 08830,USA
Chuo-Ku,Tokyo, 103 0022 Seoul - 135 778 Phone: +1-732-321-0921
Japan South Korea Fax: +1-732-321-0922
Phone: +81-3-6913-8501
Fax: +81-3-5205-2434

* *
* Premium Members

AUTOSAR Handbook © KPIT Technologies Ltd.