1. Working with

2. Renesas Technology & Solution Portfolio
The wealth of technology you see here is a direct result of the fact that Renesas Electronics Corporation was formed on April 1, 2010 as a joint venture between Renesas Technology and NEC Electronics — Renesas Technology having been launched seven years ago by Hitachi, Ltd. and Mitsubishi Electric Corporation. There are four major areas where Renesas offers distinct technology advantage.
--The Microcontrollers and Microprocessors are the back bone of the new company. Renesas is the undisputed leader in this area with 31% of W/W market share.
--We do have a rich portfolio of Analog and power devices. Renesas has the #1 market share in low voltage MOSFET solutions.
--We have a rich portfolio of ASIC solution with an advanced 90nm, 65nm, 40nm and 28nm processes. The key solutions are for the Smart Grid, Integrated Power Management and Networking
--ASSP: Industry leader for USB 2.0 and USB 3.0. Solutions for the cell phone market
-- Memory: #1 in the Networking Memory market

3. Microcontroller and Microprocessor Line-up
2010
2012
1200 DMIPS, Superscalar
1200 DMIPS, Performance
Automotive & Industrial, 65nm
600µA/MHz, 1.5µA standby
Automotive, 40nm
500µA/MHz, 35µA deep standby
500 DMIPS, Low Power
32-bit
165 DMIPS, FPU, DSC
Automotive & Industrial, 90nm
600µA/MHz, 1.5µA standby
Industrial, 40nm
200µA/MHz, 0.3µA deep standby
165 DMIPS, FPU, DSC
Industrial, 90nm
200µA/MHz, 1.6µA deep standby
Embedded Security, ASSP
Industrial, 90nm
1mA/MHz, 100µA standby
Those of you who have attended the last DevCon in 2010, the left side of this slide should look familiar. In 2010, as a result of the merger between Renesas Technology and NEC Electronics, we started offering MCU solutions based on these five cores. The R8C and 78K were mainly focusing on low end 8/16 bit applications in both automotive and industrial applications,. The RX with 32 bit CISC core was mainly offering solutions for Industrial and consumer applications.  The high-end V850 and SH cores with 32-bit RISC architecture were very successful in high end automotive and industrial applications.
Within 6 months after the merger, we launched a brand new 16-bit product family named RL78, combining the low power flash technology and the CPU core from NEC’s 78K product line and innovative peripherals from Renesas’ R8C product family. The RL78 family is a great example of the synergy effect of this merger. The RL78 is now our main focus product line for cost sensitive low power applications. It consumes only 144uA/MHz power in active mode and only 0.2uA in standby mode. With up to 44DMIPS throughput, it offers much higher performance compared to any other 8/16 microcontrollers in the market place.
The RX family continues to be our flagship 32-bit family for Industrial and consumer applications. With 100 MHz single cycle flash, 1.65DMIPS/MHz throughput and packed with connectivity peripherals it  is ideal for digital signal controller applications. Since its introduction in 2009, we are rapidly expanding the RX product line. Now we have more than 500 different RX MCUs covering from 32KB to 2MB flash memory options.
Similar to the RX, we have recently announced the launch of our next generation high-end 32 bit microcontroller architecture for automotive applications. The new family is called RH850 and provides a next-generation migration path to automotive customers currently using V850 or SH in their application. For Industrial customers currently using V850 or SH, the migration path is the RX product family. Very soon we will launch a 240MHz RX product line which can cover the need of Industrial customers requiring more than 100MHz performance.
So, in summary, from 2013 and beyond, we will mainly be focusing on the three CPU cores, RL78, RX, and RH850, to cover the broad spectrum of the industrial and automotive application space, and we will continue to support legacy architectures like R8C, 78K, SH, and V850 for existing customers.  
 In addition to the above mentioned microcontroller families, we do have an ASSP family called R-Secure which offers a wide range of products for embedded security applications. In this presentation I will mainly focusing on R-Secure product line.
25 DMIPS, Low Power
Industrial & Automotive, 150nm
190µA/MHz, 0.3µA standby
44 DMIPS, True Low Power
8/16-bit
Industrial & Automotive, 130nm
144µA/MHz, 0.2µA standby
10 DMIPS, Capacitive Touch
Industrial & Automotive, 130nm
350µA/MHz, 1µA standby
Wide Format LCDs

4. ‘Enabling The Smart Society’
Challenge: “Automotive electronic complexity is increasing exponentially. As cars become smarter with more feature content, as well as new drive-train technology and safety systems, development requires smarter tools and methods.” 
Solution:
“A solution is to standardize software design processes, tools and software. Renesas has a long history of involvement, and offers a rich portfolio of solutions to facilitate this effort. This class will introduce the concepts, processes, and challenges of implementing AUTOSAR.”
This is where our session, 0C13B, Working with AUTOSAR is focused within the ‘Big picture of Renesas Products’, Microcontroller and Microprocessors.

5. Agenda
Basics- Who is AUTOSAR?
Basics- What’s the problem?
Basics- When is AUTOSAR coming?
Basics- What is defined?
Basics- How does it work?
ECU Configuration
Challenges
Wrap-up
Takeaways

6. Basics- Who is AUTOSAR?

7. AUTOSAR Initial discussions in 2002 Official since 2003
AUTomotive Open System ARchitecture
“Cooperate on standards, compete on implementation”
Initial discussions in 2002
Official since 2003
Started with 5 German companies
NEC Electronics Corp. and Renesas Technology Corp. joined the effort in 2004
Approx. 175 Partners now (still growing)
Ideally, competition drives quality up and cost down. In addition, none of the individual players in the realm of standard automotive embedded software is large enough to be able to provide a single-source business model with the necessary support and services across the entire industry.
An earlier effort to accomplish this end was OSEK “Offene Systeme und deren Shnittstellen fur die Elektronik im Kraftfahrzeug” (“Open Systems and the Corresponding Interfaces for Automotive Electronics”), with many of the same players involved. Founded in May 1993, with BMW, Bosch, Daimler-Benz, Opel, Siemens (now Continental), Volkswagen and IIIT (Institute of Industrial Information Technology) of the University of Karlsruhe.

8. AUTOSAR – Partnership Structure
Core Partner (OEM & Tier 1 Supplier)
Organizational control
Definition of external information (web release, clearance, etc.)
Technical contributions
Administrative control
Leadership of working groups
Involvement in working groups
Membership Rights:
Premium (dues: Euro 17,500 per year):
Right to use the AUTOSAR technology royalty-free and with a free-of-charge license for automotive applications
Access to current information and specifications
Leadership of and cooperation in working groups
Access to AUTOSAR related IP of all other AUTOSAR members free of charge
Associate (dues: Euro 10,000 per year):
Access to early information and the results of the development via administrator or homepage
Development (dues: N/A):
Access to current and relevant information and specifications
Cooperation in working groups
Attendees (dues: N/A):
Source:
Premium Members
(incl. Tool Manufacturers)
Leadership of working groups
Involvement in working groups
Technical contributions
Access to current information
Associate Members
Access to finalized documents
Utilization of standards

9. AUTOSAR – Partnership Structure
Core Partners
Premium Members
Growing Community
Please find updated info on
The AUTOSAR partners are the Who’s Who of Automotive Electronics, from OEMs to Tier 1 suppliers, silicon vendors like Renesas, and tool and software vendors.
There are also some non-automotive companies which are joining the mix. Volvo Trucks and Navistar produce heavy trucks, and Caterpillar makes agricultural and construction/earth moving equipment. AUTOSAR is expanding into these and other related non-automotive spaces.
Associate Members

10. Basics- What’s the Problem?

11. Example - Automotive Integrated Center Stack
A view of an automotive infotainment system of yesteryear. This vehicle had exactly 0 microprocessors and 0 lines of software running it.

12. Example - Automotive Integrated Center Stack
This is a view of a similar vehicle from the 2013 model year line-up. In this picture, not counting the instrument cluster or modules contained in the steering wheel, there are 3-6 ECUs, some of which may contain multiple processors.
Despite the many options and buttons shown here, the feature content shown here is relatively average for a new vehicle in the U.S. Vehicles with navigation and telematics systems may contain twice this number of processors, or even more, and this is just one sub-system.
In the power-train arena, older vehicles with computer-controlled drive-trains may make use of only 1-2 microprocessors. Hybrid and full-electric vehicles, however, may contain close to 30 processors, just to manage the batteries and make the vehicle move.
Chassis systems are not lagging behind in this race, either. Systems like active suspension are another example where 15 years ago no computer processing took place on the vehicle at all, and now there are 5 or more microcontrollers driving the system.

13. How much code? 1.7M 5.7M 10M 100M Upper left: F-22 Raptor
Upper right: F-35 Joint Strike Fighter
Middle: Boeing 787 Dreamliner
Bottom: MB S-class
Manfred Broy, a professor of informatics at Technical University, Munich estimates near 100M lines of code in a premium automobile.
100M
Source:

14. Reasons for the effort Rising Automotive electronic complexity
Quantity of software increasing
ECU counts increasing
Large number of disparate processors used
Software portability limited
High effort for reuse of software features
Customized solutions increase:
Maintenance cost
Testing effort
OEM integration effort
Risk

15. Overall Objectives of AUTOSAR
Standardization
Workflows, software interfaces, tools
Increase modularity and transferability of features
Process to manage feature allocation
Clear division of hardware dependent and standard software versus the higher level features
Facilitate collaboration
Draw on experience from domain experts
Increase dependability and quality
Reuse standard solutions among Tier 1’s and across OEMs
Reduce effort/time to market

16. Basics- What is Defined?

17. System Configuration
Tools have been devised to define features, allocate them to software components (defining the interconnections) and deploy them to ECUs in the system.
Source:

18. ECU Configuration Basic Software (BSW)
AUTOSAR
SW-C 1
AUTOSAR
SW-C 3
AUTOSAR
SW-C 7
AUTOSAR
SW-C 12
AUTOSAR
Interface
AUTOSAR
Interface
AUTOSAR
Interface
AUTOSAR
Interface
AUTOSAR Runtime Environment (RTE)
AUTOSAR
Interfaces
Basic Software (BSW)
Services and Hardware Abstraction
AUTOSAR
Interface
Complex
Device Drivers
Other tools allow the configuration of the software necessary to provide these components with the necessary inputs/outputs and interconnections.
The RTE, similar to the VFB, makes it possible to move features and processing among ECUs in a way which is mostly automated. The abstraction layers remove the necessity to have the feature processing done all in one place, as the component does not need to have any awareness of the other components resident in the same ECU.
Standardized Interfaces
MicroController Abstraction Layer
Standardized Interfaces
ECU Hardware
Source:

19. Basics- When is AUTOSAR Coming?

20. AUTOSAR is Here Two things to note here:
1. The use of AUTOSAR is increasing exponentially.
- AUTOSAR Members are responsible for about 80% of car production world-wide.
- By 2016, approx 25% of ECUs will be AUTOSAR-based.
2. There are several versions of AUTOSAR which are in development and/or production right now.
- Each successive version adds functionality while attempting to further optimize the implementation of the existing feature set. For instance, 3.x optimized the communication network management layers by removing a layer and integrating that functionality into another of the layers. 4.x additions are shown on the following slide.
- 2.X is already reaching it’s peak.
- 3.X is just coming into mass production, but will begin to taper off as 4.x takes off.
Source:

21. R4.0 Additions Multi Core Cryptography Functional safety Ethernet
Main impact will be on OS
System impact (power saving, memory sharing)
Software reuse from low end to high end
Cryptography
Hardware accelerations (ICU, SHE)
AUTOSAR software libraries
Functional safety
Development processes
Safety-related features (Core test, RAM test, ROM test, etc.)
Ethernet
Legal requirement for OBD-II
Investigation to use Ethernet as network backbone

22. Basics- How does it Work?

23. AUTOSAR Runtime Environment (RTE) MicroController Abstraction Layer
3rd Party Software
Goal is to create a complete AUTOSAR solution
Renesas supplies MicroController Abstraction Layer
(MCAL – hardware-dependent software) drivers for standard peripherals and communication interfaces.
ECU Hardware
AUTOSAR Runtime Environment (RTE)
AUTOSAR
SW-C 1
SW-C 3
Basic Software (BSW)
Complex
Device Drivers
MicroController Abstraction Layer

24. Microcontroller Drivers Communication Drivers
MCAL Components
Microcontroller Drivers
Memory Drivers
Communication Drivers
I/O Drivers
GPT Driver
Watchdog Driver
MCU Driver
FLS Driver
FEE Driver
SPI Driver
SPI Driver
LIN Driver
CAN Driver
FlexRay Driver
Ethernet Driver
ICU Driver
PWM Driver
ADC Driver
DIO Driver
PORT Driver
Shown above are the MCAL components for AUTOSAR 4.x.
AUTOSAR 3.x includes the same mix of components, except for Ethernet.
Standard Peripheral Abstraction Layer (SPAL) includes all but CAN, LIN, FlexRay and Ethernet. SPI is part of the SPAL.
ECU Hardware
Source:

25. MCAL Development Roadmap
Safety /
Chassis
Autosar Release
Body
Powertrain
Airbag
Instrumentation
ADAS
Schedule
RH850F1X
RH850/P1X
RH850/E1X
RH850/R1X
RH850/D1X
RH850/V1X
2013
V850/Fx4L
AS4.0
2012
V850/Fx4
V850/Px4
V850/Dx4
2012
RH850F1X
RH850/P1X
RH850/E1X
RH850/R1X
RH850/D1X
RH850/V1X
2013
V850/Fx4L
available
AS 3.x
V850/Fx4
V850/Px4
SH2A
V850/Dx4
available
V850/Fx3
available
R32C
available
V850/Fx4
V850/Px4
SH2A
available
AS 2.1
V850 /Fx3
available
R32C
available

26. AUTOSAR Runtime Environment (RTE) MicroController Abstraction Layer
3rd Party Software
What about non-standard peripherals?
Renesas and partner companies can supply complex device drivers.
ECU Hardware
AUTOSAR Runtime Environment (RTE)
AUTOSAR
SW-C 1
SW-C 3
Basic Software (BSW)
Complex
Device Drivers
MicroController Abstraction Layer

27. AUTOSAR Runtime Environment (RTE) MicroController Abstraction Layer
3rd Party Software
Tier 1 and/or 3rd party software vendor(s) contribute the Basic SoftWare (BSW - hardware-independent software)
Tier 1 or 3rd party software vendor(s) contribute the RunTime Environment (RTE – top-level abstraction software)
ECU Hardware
AUTOSAR Runtime Environment (RTE)
AUTOSAR
SW-C 1
SW-C 3
Basic Software (BSW)
Complex
Device Drivers
MicroController Abstraction Layer

28. 3rd Party Software
Integration is a joint activity with Renesas and the 3rd party vendor
Joint project planning
Issue tracking tools
Regular meetings
Renesas is open to working with any BSW provider.

29. ECU Configuration

30. Software Design Process
application idea
HW User Manual
SW implementation
HW/SW integration

31. Software Design Process
application idea
SW development flow will change:
Configuration Tool replaces hand-coded configuration
System configuration
Integration of top-level application & low-level software
HW/SW integration

32. XML as an exchange format
Schema ECU Configuration Parameter Definition Template
conforms to
Schema ECU Configuration Description Template
ECU
Configuration
Editor(s)
XML ECU Configuration Parameter
Definition
XML ECU Configuration Description
read
back
creates
Input and output formats are standardized by AUTOSAR
This ensures that any AUTOSAR compatible configuration editor can be used

33. “ECU Spectrum” Editor Tool
A simple configuration editor is included in the Renesas MCAL package free of charge
Generic tool for “quick start” and testing that offers:
AUTOSAR compatible xml file read / write
Basic validation checks
Read-back of existing configuration descriptions

34. ECU Configuration (Overview)
Configuration Data generated for the AUTOSAR module
Extract of the System Description
Configuration Parameter
Definition
(Module MCU)
.xml
ECU
Configuration
Description
Editor(s)
.xml
Module
Generator
Configuration
Files
(.c .h)
Standardized definition format per module:
Type, allowed range, multiplicity, default values etc.
This is a precise description with information about:
Number of instances (e.g. channel no.)
parameter value definitions
The Generator translates the configuration information into source code that is then used by the driver module

35. Generators
ECU
Configuration
Description
Module
Generator
Configuration
Files
(.c .h)
.xml
Executable
Implementation specific tool to generate code that contains the configuration data from the AUTOSAR configuration description file(s)
Renesas delivers Generators as command line executables (one for each software module)
Command line interface that take the ECU configuration description file as input
Generate .h files (for pre-compile configuration) and .c files (for link-time and post-build configuration)
Are written in perl
Renesas Generators provide plug-in capability for configuration editors and can be used in makefile environment

36. Challenges

37. What are some possible downsides to hardware abstraction?
Questions
What are some possible downsides to hardware abstraction?
What are some possible downsides to commonization and standardization?

38. Challenges – Hardware Abstraction
Layered approach provides great flexibility, but
it increases configuration complexity and the number of chances to “get it wrong”
Tools have to balance ease of use against the restriction of this flexibility
Becomes

39. Challenges – Standardization
Standard API
Designed for the
“Least Common Denominator”
Decreases the advantage of innovation
Non-standard features may not be available
Special features must be either
made transparent to BSW by MCAL, or
handled outside of MCAL by “complex device drivers”
Software Supply Chain
BSW from multiple vendors must work together
Integration and runtime issue resolution requires
cooperation , potentially among competitors =

40. Challenges – Commonization
Specifications still under development
Released versions available, but not all changes/updates are backward-compatible, even within minor revisions
OEMs adopt at different times and for different reasons.
Support of multiple releases necessary to support legacy and future development
Historically, OEMs have different interpretations or desired features which are not agreed upon
OEM-specific AUTOSAR implementations increase complexity
More is standardized in later revisions to avoid this.

41. Wrap-Up

42. Pitfalls to Avoid - Possible Misconceptions
“AUTOSAR-compliance is a precise concept”
Full process
Black box behavior
Everything in-between
“Common API” means the processor no longer matters
Analogy – Windows and x86 -> Intel’s HTT
Processor architectures, instruction sets, pipelines, and special peripherals and features can make all the difference.
“Common API” means “cheaper and faster to market”
True, but only after reuse is factored in. Change costs money.
“Standard” means “Easy”

43. DO NOT OPEN! Optimizations “AUTOSAR” “AUTOSAR”
Herstellerinitiative Software (HIS) recommended optimization AUTOSAR
Subset specification
Allows application to 16-bit and
smaller/less powerful 32-bit microcontrollers
Similar initiative from JASPAR
Black box AUTOSAR-compliance
Complex Device Drivers
Implement leaner hardware access for time-critical features
Control unspecified hardware peripherals (e.g. RDC, EMU)
DO NOT
OPEN!
“AUTOSAR”
“AUTOSAR”
HIS consists of 5 German OEMs: Audi, BMW, Daimler, Porsche and Volkswagen
JASPAR is “Japan Automotive Software Platform and Architecture”. It is made up of Japanese OEMs and Suppliers: Toyota, Nissan, Honda R&D, Toyota Tsusho Electronics, and Denso Corp.

44. Takeaways Implement the subset that makes sense
AUTOSAR is not an end in itself
“Don’t sacrifice usability for the sake of reusability.”
Get help from the experts
Save money in the long run by getting it right from the start
Reap the benefits of lessons learned by others
HIS consists of 5 German OEMs: Audi, BMW, Daimler, Porsche and Volkswagen
JASPAR is “Japan Automotive Software Platform and Architecture”. It is made up of Japanese OEMs and Suppliers: Toyota, Nissan, Honda R&D, Toyota Tsusho Electronics, and Denso Corp.

45. Questions?

46. ‘Enabling The Smart Society’ in Review…
Challenge: “Automotive electronic complexity is increasing exponentially. As cars become smarter with more feature content, as well as new drive-train technology and safety systems, development requires smarter tools and methods.”  
“One solution is to standardize software design processes, tools and software. Renesas has a long history of involvement, and offers a rich portfolio of solutions to facilitate this effort. This class will introduce the concepts, processes, and challenges of implementing AUTOSAR.”
Do you agree that we accomplished the above statement?