Chapter 3: 

Software Platform & 
Architecture for Telematics
Content
• ECU
• Automotive Open System 
Architecture (Autosar)
– An open standardized software 
architecture for the automotive 
industry
– Special thanks to Simon Fürst, 
BMW
• 1st AUTOSAR Open Conference & 8th 
AUTOSAR Premium Member 
Conference
• October 23rd, 2008, Cobo Center, 
Detroit, MI, USA
2 2010/2/3
 ECU
• Electronic Control Unit
– 行車電腦, 車載電腦
– is an embedded system that controls one or more 
of the electrical systems or subsystems in a 
vehicle
• CPU, memory, I/O, A/D, Other Devices

3 2010/2/3
 ECU
• Some modern cars have up to 80 ECUs, including
– Engine Control Unit ‐ also known as an ECU 
– Transmission Control Unit ‐ TCU 
• the above two may be combined, and referred to as a Powertrain Control 
Module (PCM) 
– Airbag control unit ‐ ACU 
– Telephone Control Unit ‐ TCU 
– Man Machine Interface ‐ MMI 
– Body Control Module ‐ controls door locks, electric windows, 
courtesy lights etc. 
– Door Control unit 
– Seat Control Unit 
– Climate Control Unit 
– speed control unit 
– Convenience control unit ‐ CCU 

(From WIKI) 4 2010/2/3

 Exmaple of ECU
1. Wheel speed sensor 
2. Rear differential oil temperature switch 
3. Wheel speed sensor 
4. Manual mode switch 
5. Manual control dial 
6. DCCD electronic control unit 
7. Parking brake switch 
8. DCCD indicator lights 
9. Battery 
10. ABS control unit 
11. Wheel speed sensor 
12. Brake light switch 
13. Throttle position sensor 
14. Accelerator pedal 
15. Wheel speed sensor 
16. Lateral G sensor (with yaw rate sensor for 2005) 
17. Main gear input from the engine 
18. Front output 
19. Rear output 
20. Transmission assembly 
21. Center differential 
22. ABS monitor signal 

Resource:
5 SUBARU driver performance
2010/2/3
ECU
• Based on information from the input 
sensors(engine coolant temperature, 
barometric pressure, air flow etc.) the ECU 
determines optimum setting for the output 
actuators. (injection, idle speed, ignition 
timing, etc.)

6 2010/2/3
AUTOSAR Tutorial

Reference 
http://www.autosar.org
Autosar
• Cooperate on standards – compete on 
implementation

8 2010/2/3
Managing Complexity by Exchangeability and 
Reuse of Software Components

9 2010/2/3
Project Objectives and Main Working 
Topics

10 2010/2/3
Main Working Topics

11 2010/2/3
Technical scope of AUTOSAR

12 2010/2/3
Benefits from AUTOSAR

13 2010/2/3
AUTOSAR – Core Partners and Members

14 2010/2/3
Use Case ‘Pedal Management’ view for 
one ECU
• Implementation of functions independent on 
distribution on different ECU as communication will 
be done via ECU‐individual AUTOSAR‐RTE exclusively

15 2010/2/3
Use Case ‘Pedal Management’ view for 
two ECUs

16 2010/2/3
Use case ‘Front‐Light Management’ in 
AUTOSAR

17 2010/2/3
Exchange of type of front‐light

18 2010/2/3
Distribution on ECUs

19 2010/2/3
Use case ‘Front‐Light Management’ in 
AUTOSAR

20 2010/2/3
AUTOSAR Key Topics
• AUTOSAR provides three main areas of results
– Architecture:
• Software architecture including a complete basic 
(environmental) software stack for an ECU as an integration 
platform for hardware independent SW applications
– Methodology:
• Exchange formats (templates) to enable a seamless 
configuration process of the basic software stack and the 
integration of application software in ECUs
– Application Interfaces:
• Specification of application interfaces as a standard for 
application software modules

21 2010/2/3
Main Concepts: Architecture
• Basic Software modules
• Run time environment and communication
• Results of sample implementation in 
„Validator 2“

22 2010/2/3
Main Concepts: Architecture
• Standardized AUTOSAR interfaces will support HW 
independence and enable the standardization of SW 
components.

23 2010/2/3
AUTOSAR Basic Software

24 2010/2/3
AUTOSAR Basic Software Modules

25 2010/2/3
 Intra‐ and Inter‐ECU Communication
• Ports implement the 
interface according to 
the communication 
paradigm (here client‐
server based).
• Ports are the 
interaction points of a 
component.
• The communication is 
channeled via the RTE.
• The communication 
layer in the basic 
software is 
encapsulated and not 
visible at the 
application layer.

26 2010/2/3
Validation of AUTOSAR Release 2.0

27 2010/2/3
Used Release 2.0 AUTOSAR specifications

28 2010/2/3
Used Release 2.0 AUTOSAR specifications

29 2010/2/3
 Development of
AUTOSAR SW Components

Markus Maier / ETAS GmbH
Resource form p.3‐7, 10
Software‐ and System‐Architecture of ECUs

• Automotive Software Development will change

• Hardware- and software will be widely independent of each other.

•Development processes will be simplified.
• This reduces development time and costs.
•Reuse of software increases at OEM as well as at suppliers.
•This enhances also quality and efficiency.
31 2010/2/3
Software‐ and System‐Architecture of ECUs

• Today: Proprietary Software‐Architecture

32 2010/2/3
 Software‐ and System‐Architecture of ECUs

• Tomorrow: AUTOSAR – Standardized Software Architecture

33 2010/2/3
Software‐ and System‐Architecture of ECUs

• Today: ECU network

34 2010/2/3
Software‐ and System‐Architecture of ECUs

35 2010/2/3
Software‐ and System‐Architecture of ECUs

• Future: Function oriented Architecture for higher Flexibility

36 2010/2/3
Software‐ and System‐Architecture of ECUs
• What disappears?
– Proprietary Basic Software with proprietary interface towards 
the application software
• What comes up?
– Standardized Basic Software Modules
– RTE (Runtime Environment) make application software 
independent from Basic SW and specialities of ECU hardware
– Application SW Components with standardized interface 
description (syntax and specific signals)
• What stays?
– Application Software as a brand differentiating key element for 
the development of new vehicle functions

37 2010/2/3
Development of AUTOSAR SW Components

• Model based Methods and Tools ‐ Overview

38 2010/2/3
Development of AUTOSAR SW Components

• Following the AUTOSAR Methodology, the 
E/E architecture is derived from the formal 
description of software and hardware 
components.

39 2010/2/3
Development of AUTOSAR SW Components

40 2010/2/3
Development of AUTOSAR SW Components

41 2010/2/3
Development of AUTOSAR SW Components
• To configure the system, input descriptions of all software components, 
ECU resources and system constraints are necessary.

42 2010/2/3
Development of AUTOSAR SW Components

• The system configuration maps software components to 
ECUs and links interface connections to bus signals.

43 2010/2/3
AUTOSAR – System Design – Implementation Process

44 2010/2/3
AUTOSAR – The Virtual Functional Bus
• Input to the System Design on an abstract level

45 2010/2/3
AUTOSAR – Input Descriptions
• Step 1a): Description of SW‐Components independently of hardware

46 2010/2/3
AUTOSAR – Input Descriptions
• Step 1b): Description of hardware independently of application software

47 2010/2/3
AUTOSAR – Input Descriptions
• Step 1c): Description of system

48 2010/2/3
AUTOSAR – System Configuration
• Step 2: Distribution of SW‐Component‐Descriptions to ECU

49 2010/2/3
AUTOSAR – ECU‐Configuration
• Step 3: Generation of required configuration for AUTOSAR‐Infrastructure 
per ECU

50 2010/2/3
AUTOSAR – Generation of Software Executables

• Step 4: Based on the configuration information for each ECU (example 
ECU1)

51 2010/2/3
Use case ‘Front‐Light Management’ in AUTOSAR

52 2010/2/3