Working with

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

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

‘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.

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

Basics- Who is AUTOSAR?

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) www.autosar.org 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.

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: www.autosar.org 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

AUTOSAR – Partnership Structure Core Partners Premium Members Growing Community Please find updated info on www.autosar.org 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

Basics- What’s the Problem?

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.

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.

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: http://spectrum.ieee.org/green-tech/advanced-cars/this-car-runs-on-code/0

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

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

Basics- What is Defined?

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: http://www.autosar.org

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: http://www.autosar.org

Basics- When is AUTOSAR Coming?

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: http://www.autosar.org

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

Basics- How does it Work?

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

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: http://www.autosar.org

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

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

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

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.

ECU Configuration

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

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

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

“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

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

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

Challenges

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?

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

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 =

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.

Wrap-Up

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”

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.

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.

Questions?

‘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?