Sensors Actuators ECU Hardware Development OEM Supplier System Architecture Function Network Function Mapping ECUs Communication Gateways Busses Wiring Harness Development Integration Conformance Network System Function Vehicle ECU Loops (caused by reviews, simulation and prototyping) ECU A Supp. X ECU B Supp. Y ECU C Supp. Z Development Process for Distributed Functions in Vehicle Network Systems by Migration to AUTOSAR 2010-03-12, Shenzhen V1.0 2010-02-25
Agenda > Vector Introduction Overview on AUTOSAR System Development Process for the OEM System Development Process for the Supplier ing AUTOSAR based ECUs ing AUTOSAR based Vehicles Summary Slide: 2
Vector Introduction Our Values Vector is independent. All Vector shares are held by the management. Our strategies can therefore be fully orientated on our customers expectations. Vector thinks ahead. We are already developing today the technology for tomorrow. Vector is a partner. Our work is defined by an intense and bilateral dialog with both customers and employees. Vector is worldwide. We are present in all markets relevant for our customers with subsidiaries or sales distributors. Slide: 3
Vector Introduction Application Areas and Product Examples Development of Distributed Systems DaVinci Network er ECU Software MICROSAR, oscan, SW components ECU ing CANoe, CANalyzer, VT System Spec ECU Report passed Vehicle Diagnostics CANdela ECU Calibration CANape Process Management easee, Consulting Services Vector offers Solutions for... > Slide: 4
Vector Introduction Tools More than 10 years ago: Cooperation with Daimler to develop a tool for the description of distributed systems ( TITUS ) But: The industry was not ready for such a sophisticated approach Vector continued the tool development and released DaVinci for function and network design DaVinci is now the AUTOSAR tool suite for software design, configuration and testing Slide: 5
Vector Introduction Basic Software Since more than 15 years: Vector provides configurable Embedded Basic Software for Communication and Diagnostics Microcontroller dependent drivers were developed in close cooperation with the semiconductor manufacturers Single sources were used to share the non-competitive, basic algorithms with our customers Vector was the first independent vendor of Basic Software and initiated significantly the idea of Software as a Product Slide: 6
Agenda Vector Introduction > Overview on AUTOSAR System Development Process for the OEM System Development Process for the Supplier ing AUTOSAR based ECUs ing AUTOSAR based Vehicles Summary Slide: 7
Overview on AUTOSAR Goal of AUTOSAR Establish a de-facto standard for an Automotive Open System Architecture (AUTOSAR) in order to increase exchangeability of SW modules between OEMs and suppliers Slide: 8
Overview on AUTOSAR What is AUTOSAR? Development Partnership of leading vehicle manufacturers and suppliers. Slide: 9
Overview on AUTOSAR History - I Establishment of a technical team First talks between BMW, Bosch, Continental Teves, DaimlerChrysler, Volkswagen, and later Siemens VDO Official formation of the AUTOSAR (AUTomotive Open System ARchitecture) partnership Ford, Peugeot Citroën, and Toyota become Core Members General Motors joins as a Core Member 08/02 11/02 08/03 11.12/03 12/04 03/04 07/06 Vector joint AUTOSAR as premium member Vector AUTOSAR Symposium Slide: 10
Overview on AUTOSAR History - II Vector Document Owner CAN Generic Network Management Vector Document Owner ICU Vector Document Owner Flexray State Manager Vector releases BSW based on AUTOSAR 3.0 09/04 05/05 08/05 02/06 03/06 05/06 03/07 03/08 09/06 11-12/06 02/07 08/07 01/08 1 st Publication of Specifications Integration AUTOSAR Concept Specification R1.0 Methodology Validation Specification R2.1 Specification R3.0 Specification R2.0 Vector releases Prototype Bundle based on AUTOSAR 2.0 Vector releases BSW based on AUTOSAR 2.1 Vector releases Prototype Bundle based on AUTOSAR 2.1 Slide: 11
Overview on AUTOSAR History - III Vector releases Prototype BSW based on AUTOSAR 3.0 BSW platform for 2 OEMs available. Integration of OEM specific modules Vector releases complete BSW for CANoe Emulation 01/08 03/08 04/08 06/08 07/08 08/08 09/08 01/09 Concept Presentation AUTOSAR 4.0 Vector presents J1939 and Diagnostic Concepts for AUTOSAR 4.0 Specification R3.1 Vector releases Serial BSW based on AUTOSAR 3.0 Vector receives AUTOSAR Premium Member Award 70 Concepts are planned to be released in AUTOSAR 4.0 (e.g. Ethernet, J1939, Diagnostics) BSW platform for 3 OEMs available Slide: 12
Overview on AUTOSAR Reusability of functions across carlines Vehicle A Vehicle B Hardware Topology Function Library Seat Adjustment A Software Configuration Seat Adjustment B Lighting Seat Heating Air Conditioning Distributed System Code Generation Slide: 13
Overview on AUTOSAR Basic Software - Architecture Roof 80 BSW modules abstracted by 3 layers Light Dimmer RTE AUTOSAR BSW Microcontroller Service Layer ECU Abstraction Layer Microcontroller Abstraction Layer Complex Device Drivers Slide: 14
Overview on AUTOSAR Targets and Goals Abstraction of hardware from software, making development more flexible More configuration instead of implementation Standardized AUTOSAR code generation/modeling tools Improvement in software quality by standardized BSW Competition limited to OEM-relevant features Serviceability over the entire product life cycle Reusability of functions across vehicle networks and across OEM boundaries Slide: 15
Overview on AUTOSAR Elements Standardize Development Process and Data Exchange Formats Methodology + Templates Standardize Application Software Interface Description Functional Interfaces Specify Interface between Basic Software Modules and Application Runtime Environment (RTE) Application Layer AUTOSAR Runtime Environment (RTE) Define Open Reference Architecture for ECU software including Bus Behavior System Services SYS MEM MEM Communi cation Services CAN/LIN /FR I/O Hardware Com plex Driv ers Basic Software (BSW) SYS Drivers Memory Drivers COM Drivers I/O Drivers Microcontroller Slide: 16
Agenda Vector Introduction Overview on AUTOSAR > System Development Process for the OEM System Development Process for the Supplier ing AUTOSAR based ECUs ing AUTOSAR based Vehicles Summary Slide: 17
System Development Process for the OEM V Model Sensors Actuators System Architecture ECUs System ECU Hardware Development Function Network Function Mapping Gateways Busses Wiring Harness Development Integration Network Function Vehicle OEM Communication Conformance ECU Supplier Loops (caused by reviews, simulation and prototyping) ECU A Supp. X ECU B Supp. Y ECU C Supp. Z Slide: 18
System Development Process for the OEM System Architecture Sensors Actuators ECU Hardware Development ECUs System Architecture Gateways Busses Function Network Wiring Harness Function Mapping Development System Network Integration Function Vehicle OEM Communication Conformance ECU Activities Definition of Sensors and Actuators Definition of ECU Breakdown and Locations Supplier Loops (caused by reviews, simulation and prototyping) ECU A ECU B ECU C Supp. X Supp. Y Supp. Z Work Products System Architecture Specification ECU Requirement Specification (mechanical and hardware) Slide: 19
System Development Process for the OEM Function Sensors Actuators ECU Hardware Development ECUs System Architecture Gateways Busses Function Network Wiring Harness Function Mapping Development System Network Integration Function Vehicle Activities Separation of Functions into Sub-functions Definition of Function Interfaces Specification of Function Boundary Conditions Relation to Sensors and Actuators Timing Constraints Resource Consumption Conformance Communication OEM Supplier ECU A ECU B ECU C Supp. X Supp. Y Supp. Z Loops (caused by reviews, simulation and prototyping) ECU Work Products Function Interface Specification Function Behavior Specifications Function1 Virtual Function Bus VFB Function2 Function3 Slide: 20
System Development Process for the OEM Network Activities Definition of Gateways and Bus Systems Assignment of ECUs to Busses Selection of Network Technologies Specification of Networks Sensors ECUs System Actuators System Architecture Gateways ECU Hardware Busses Network Development Function Network Wiring Harness Function Mapping Development Integration Function Conformance Communication OEM Supplier ECU A ECU B ECU C Supp. X Supp. Y Supp. Z Loops (caused by reviews, simulation and prototyping) Vehicle ECU Work Products Generic Network Specifications (Protocols and Algorithms) Vehicle-specific Network Specifications (Topology and Parameters) Slide: 21
System Development Process for the OEM Function Mapping Sensors Actuators ECU Hardware Development ECUs System Architecture Gateways Busses Function Network Wiring Harness Function Mapping Development System Network Integration Function Vehicle Activities Mapping of Functions to ECUs Definition of Network Interfaces Specification of Signal Properties (e.g. latency, update rate, ) Conformance Communication OEM Supplier ECU A ECU B ECU C Supp. X Supp. Y Supp. Z Loops (caused by reviews, simulation and prototyping) ECU Work Products Function Interface Specification (refinement) ECU 2 Function 1 Function 2 CAN LIN FlexRay ECU 1 ECU n Function 3 Slide: 22
System Development Process for the OEM Communication Activities Definition of Network Messages Signal Mapping to Messages Specification of Message and Signal Attributes (e.g. send type, timings,...) Sensors ECUs System Actuators System Architecture Gateways ECU Hardware Busses Network Development Function Network Wiring Harness Function Mapping Development Integration Function Conformance Communication OEM Supplier ECU A ECU B ECU C Supp. X Supp. Y Supp. Z Loops (caused by reviews, simulation and prototyping) Vehicle ECU Work Products Communication matrix Network database Bus Simulation Slide: 23
System Development Process for the OEM Migration to AUTOSAR Function Decomposition is described by AUTOSAR compliant design tools (e.g. DaVinci) Interface description is stored in a standardized data format (System Description) and can be easily exchanged between design tools (e.g. DaVinci) and behavior modeling tools (e.g. Matlab) Boundary conditions for function mapping (e.g. resource and timing constraints) are considered in early design phases and described in a standardized format for later reuse Network Parameters are stored in a standardized format Mapping of functions to ECUs is a separate process step and described in a standardized data format Mapping of signals to messages is described in a central, standardized data format including gateway information (DBC, LDF, Fibex System Description) Slide: 24
Agenda Vector Introduction Overview on AUTOSAR System Development Process for the OEM > System Development Process for the Supplier ing AUTOSAR based ECUs ing AUTOSAR based Vehicles Summary Slide: 25
System Development Process for the Supplier V Model Vehicle OEM Conformance Function ECU Supplier ECU Architecture Software Integration Component Implementation Component Slide: 26
System Development Process for the Supplier Software Activities Refinement of Software Architecture OEM Supplier Conformance Function ECU Architecture Integration Software Component Component Implementation Vehicle ECU Data types are defined Dependencies to BSW are defined Modeling-tools can be used Work Products Reusable SWC templates and compositions Function x Composition SWC Interface definition for each SWC SWC SWC SWC SWC Slide: 27
System Development Process for the Supplier Software : DaVinci Developer Graphical editor for definition and integration of SW components Definition of runnable entities Slide: 28
System Development Process for the Supplier DaVinci Developer: Interaction with model-based development tools Example: Simulink Simulink Develop the behavior model Generate SWC implementation code SWC description (e.g. ports, runnables) is exchanged via AUTOSAR XML DaVinci Developer Integrate the SWC into the ECU SW architecture Configure the RTE Slide: 29
System Development Process for the Supplier Component Implementation Activities Vehicle Component templates are generated Functional behavior is implemented OEM Supplier Conformance Function ECU Architecture Integration Software Component Component Implementation ECU BSW and RTE are generated *.hex/ *.elf is build Work product Executable Software DaVinci Developer DaVinci Configurator Pro Slide: 30
System Development Process for the Supplier Workflows and Tool Chain Integration Model-based development tools.c/.h SWC implementation files (generated) SW Component Description xml.c/.h.c/.h SWC implementation files (legacy, hand-coded) Templates 1) DaVinci Developer 1).c/.h MICROSAR RTE files xml ECU Extract of System Description (from OEM) DaVinci Configurator Pro 2).c/.h MICROSAR BSW configuration files Basic Software Module Description xml xml ECU Configuration Description 1) Requires license of MICROSAR RTE 2) Requires license of MICROSAR BSW Slide: 31
System Development Process for the Supplier DaVinci Configurator Pro Consistency of parameter values ensured by rulebased validation concept Comfort view available for convenient editing of the parameter values of the BSW modules Overview of the BSW modules in the ECU - defined by BSW module description files Slide: 32
System Development Process for the Supplier DaVinci Configurator Pro GENy: Specialized tool for configuration of communication stack Specific views for configuring the communication frames and signals of the ECUs Automatic setup of communication parameter based on the ECU Extract of System Description Consistency of communication parameters automatically ensured Slide: 33
System Development Process for the Supplier MICROSAR Vector s AUTOSAR Basic Software Application MICROSAR RTE COMM MICROSAR COM CRC DCM NVM COM IPDUM NM PDUR MICROSAR OS OS MICROSAR SYS DET ECUM SCHM WDGM WDGIF MICROSAR DIAG DEM FIM MICROSAR MEM MEMIF EA FEE MICROSAR CAN J1939TP 1 CANTP CANNM CANSM CANIF MICROSAR LIN LINTP 2 LINSM LINIF MICROSAR FR FRTP FRNM FRSM FRIF MICROSAR IO IOHW Complex Drivers MICROSAR CAL MICROSAR EXT GPTDRV WDGDRV MCUDRV FLSDRV EEPDRV CANDRV LINDRV FRDRV SPIDRV ICUDRV PWMDRV ADCDRV DIODRV PORTDRV DRVEXT 1 CANTRCV LINTRCV 1 FRTRCV Microcontroller Standard Software Project and services 1 Available extensions for AUTOSAR3.0 BAM and CMDT Option available 2 Option included in LINIF Slide: 34
System Development Process for the Supplier Component Activities: Each SWC is tested regarding its OEM Supplier ECU Architecture Software Conformance Function Integration Vehicle ECU interfaces Component Implementation Component functionality Solution: DaVinci Component er of atomic SWC or compositions possible Executes the original SWC implementation, compiled for the PC Emulates the RTE Slide: 35
System Development Process for the Supplier DaVinci Component er: Concept Goal: test of functional SWC behavior on the PC Solution: DaVinci Component er Emulates the RTE: Executes the original SWC implementation, compiled for the PC Dynamically configured via AUTOSAR XML of atomic SWC or compositions possible and Stimulation CANoe Environment Simulation Visualization and logging Open interface to connect testing tools like CANoe or NUnit (an open source tool) Set inputs Update simulation time Read outputs SWC-under-test SWC Description SWC-under-test Runnable1 xml Runnable2.c/.h SWC Implementation DaVinci Component er Slide: 36
System Development Process for the Supplier Migration to AUTOSAR Software is consequently derived from the Function by further decomposition down to atomic software components Easy use of different modeling tools by using standardized data formats (System Description) Complete abstraction of the Application Software Components from the Basic Software by the RTE (Runtime Environment) Easy reuse of Software is possible Interfaces between Application Software Components are described in a standardized data format Standardized interfaces of the Basic Software are defined Paradigm change for software development Comprehensive functionality of the Basic Software reduces implementation activities in favour of configuration and integration activities Further use of modeling tools reduces implementation activities in favour of code generation Specific tools for component tests can use standardized data formats and RTE abstraction (RTE emulation on a PC environment) Slide: 37
Agenda Vector Introduction Overview on AUTOSAR System Development Process for the OEM System Development Process for the Supplier > ing AUTOSAR based ECUs ing AUTOSAR based Vehicles Summary Slide: 38
ing AUTOSAR based ECUs V Model Vehicle OEM Conformance Function ECU Supplier ECU Architecture Software Integration Component Implementation Component Slide: 39
ing AUTOSAR based ECUs Integration Activities Vehicle complete ECU software (BSW+RTE+Appl) OEM Supplier ECU Architecture Software Conformance Function Integration ECU Component Implementation Component Solution Complete ECU software runs on a PC target by using an emulated Basic Software CANoe / TAE module CAN LIN FlexRay Complete MSR-Stack Simululated ECU simulated bus (real time) Slide: 40
ing AUTOSAR based ECUs CANoe as PC Target for AUTOSAR ECU Emulation Goal PC as easy-to-use target for initial integration of Basic SW and applications Reuse the ECU configuration when migrating to the real target Solution Complete ECU code runs as DLL during CANoe simulation Based on an emulation of AUTOSAR OS and CAL I/O mapped to CANoe environment variables PC with CANoe Simulation of I/O via panels Application 3 Access of physical buses and I/O via PC interfaces CANoe OS Emu CANoe MCAL Emu Complex Drivers Microcontroller Physical Bus Slide: 41
ing AUTOSAR based ECUs Conformance Activities Measure degree of specification fulfillment regarding OEM Supplier Conformance Function ECU Architecture Integration Software Component Component Implementation Vehicle ECU Network specification Function specification Solution Remaining Bus Simulation Algorithm and Protocol Libraries AUTOSAR NM AUTOSAR TP CANoe Feature Set Creation of test cases with TAE XML Module Generation XML/HTML test report is generated Slide: 42
ing AUTOSAR based ECUs Function Activities Complete test of ECU Function Requirements as interaction between sensors and actuators OEM Supplier Conformance Function ECU Architecture Integration Software Component Component Implementation Vehicle ECU Solution: Stimulation of actuators and observation of actuators by VT System Reuse of Remaining Bus Simulation and CANoe Feature Set Slide: 43
ing AUTOSAR based ECUs Migration to AUTOSAR ECU Software Integration on emulated targets (PC) instead of using the real hardware Standardized Network Conformance because of standardized protocols Standardized data format (System Description) allows reuse of system parameters for test configuration Slide: 44
Agenda Vector Introduction Overview on AUTOSAR System Development Process for the OEM System Development Process for the Supplier ing AUTOSAR based ECUs > ing AUTOSAR based Vehicles Summary Slide: 45
ing AUTOSAR based Vehicles Vehicle OEM Conformance Function ECU Supplier ECU Architecture Software Integration Component Implementation Component Slide: 46
ing AUTOSAR based Vehicles V Model Sensors Actuators System Architecture ECUs System ECU Hardware Development Function Network Function Mapping Gateways Busses Wiring Harness Development Integration Network Function Vehicle OEM Communication Conformance ECU Supplier Loops (caused by reviews, simulation and prototyping) ECU A Supp. X ECU B Supp. Y ECU C Supp. Z Slide: 47
ing AUTOSAR based Vehicles Activities Integration Verification of interoperability of ECUs on a test board as precondition for building a test vehicle Solution Using CANoe as monitoring tool Reuse of Remaining Bus Simulation and CANoe Feature Set Slide: 48
ing AUTOSAR based Vehicles Network Activities Intensive test of each network on a test board or in a test vehicle Solution CANstress and CANscope for the verification of the Physical Layer including the final wiring harness Reuse of Remaining Bus Simulation and CANoe Feature Set Slide: 49
ing AUTOSAR based Vehicles System Activities Intensive test of the complete system in a test or a prototype vehicle Multiple Networks Gateways Sensors and Actuators Regression test of the complete system Solution Reuse of Integration, Network and Function Slide: 50
Agenda Vector Introduction Overview on AUTOSAR System Development Process for the OEM System Development Process for the Supplier ing AUTOSAR based ECUs ing AUTOSAR based Vehicles >Summary Slide: 51
Summary Migration to AUTOSAR AUTOSAR supports the whole development process with focus on and Software Component Development by Same understanding of the process at all development partners Unified definitions and terminologies Standardized data formats containing all required information for Software Components and ECUs Abstraction of Application Software Components and Basic Software for distributed development Standardized network protocols for an easy system integration Easy reuse and mapping of Application Software Components Sensors Actuators ECU Hardware Development OEM Supplier System Architecture Function Network Function Mapping ECUs Communication Gateways Busses Wiring Harness Development Integration Conformance Network System Function Vehicle ECU ECU A Supp. X ECU B Supp. Y ECU C Supp. Z Slide: 52
Summary AUTOSAR and Vector s Participation Vector is part of AUTOSAR Vector has brought broad know how into AUTOSAR since the beginning Vector employees are working in development teams of AUTOSAR Ford Slide: 53
Summary AUTOSAR @ Vector Since beginning of 2004 Vector has been an active participant in defining the AUTOSAR standard. The AUTOSAR Consortium honoured Vector's commitment in 2007 with the first AUTOSAR Premium Member Award. Vector provides you with everything you need to develop ECUs conform to the AUTOSAR standard. Vector offers modules adapted for many different hardware platforms in cooperation with the relevant semiconductor manufacturers. Slide: 54
Thank you for your attention. For detailed information about Vector and our products please have a look at: www.vector.com Author: Peter Liebscher Vector Informatik GmbH Shanghai Representative Office No. 70 Cao Bao Road Shanghai Slide: 55