Global Automotive E/E Standard. Rick Flores, General Motors, AUTOSAR Steering Committee Open Architecture Summit Washington, D.C.

Transcription

1 Global Automotive E/E Standard Rick Flores, General Motors, Steering Committee Open Architecture Summit Washington, D.C. November 4, 2014

2 E/E innovations in vehicle development increases Major innovations are fully based on E/E 90% of all innovations Infotainment Linked networks Mechanics Electronic support rd October, 2013 The Global Automotive E/E Standard

3 companies found 3 23rd October, 2013 The Global Automotive E/E Standard

4 has Become a Global Standard Europe: 91 Partners America: 27 Partners Asia: 67 Partners Africa: 1 Partner 4 October 22, th Open Conference

5 Overview Motivation and Partnership Organization and Processes Worldwide and other Standards Outlook Guided Tour (Part 1)

6 Overview Motivation and Partnership Organization and Processes Worldwide and other Standards Outlook Vision and Objectives Cooperation and Partner Status Guided Tour (Part 1) Motivation and Principles

7 Main Working Topics Architecture Application Interfaces Methodology Architecture: Software architecture including a complete basic software stack for ECUs the so called Basic Software as an integration platform for hardware independent software applications. Architecture Application Interfaces Methodology Methodology: Defines exchange formats and description templates to enable a seamless configuration process of the basic software stack and the integration of application software in ECUs. It includes even the methodology how to use this framework. Architecture Application Methodology Interfaces Application Interfaces: Specification of interfaces of typical automotive applications from all domains in terms of syntax and semantics, which should serve as a standard for application software Guided Tour (Part 1) Motivation and Principles

8 Running the partnership: Three tier partnership structure Core Partners Organizational control Administrative control Associate Partners Users of the standard Premium Partners Leadership of Working Groups Involvement in Working Groups Development Partners Dedicate expertise contributions Involvement in Working Groups 23rd 8 October, 8 The Global Automotive E/E Standard

9 Partners (March 2014) Up-to-date status see: Guided Tour (Part 1) Motivation and Principles

10 Vision aims to improve complexity management of integrated E/E architectures through increased reuse and exchangeability of SW modules between OEMs and suppliers June 2014, Munich The Future of

11 The Principles of the Development Cooperation Core-, Premium- and Development Partners jointly develop a common automotive standard Partners grant each other a non-exclusive, non-transferable license under its essential intellectual property rights Partners do not assert against each other when commercially exploiting the standard As part of their exploitation of, Partners developed compliant products Partners commit for product conformance to specifications to ensure interoperability Product conformance Cooperate on standards, compete on implementation Guided Tour (Part 1) Motivation and Principles

12 Running the partnership: Exploitation license valid for automotive applications Automotive Applications means applications related to engine powered, land-based, non-railed vehicles, such vehicles intended for primary transportation purposes rd October, 2013 The Global Automotive E/E Standard

13 Running the partnership: Exploitation license valid for derived applications Civil machineries Ultra hazardous activities Marine including military marine transportation vessels, railway powertrain, agriculture and forest machinery, construction and mining machinery, compressors and pumps, or power generators. aerospace and aviation, nuclear power, chemical and/or biological reactors, petrochemical, or military (except for military marine transportation vessels) rd October, 2013 The Global Automotive E/E Standard

14 Overview Motivation and Partnership Processes and Organization Worldwide and other Standards Outlook Life cycle model and concept handling process Release Phases Management boards and work packages Guided Tour (Part 1) Organization and Processes

15 Release Phases Phase II Phase III Today Continuation Development of Architecture and Methodology Selective Enhancements Stabilization Rel. 4.0 Rel. 4.0 Rel. 4.1 Rel. 4.2 Rel. 3.1 Rel. 3.2 Maintenance and support of the exploitation Rel (LoKI*) Rel. 2.x (LoKI*) *Loki = List of known issues Development Evolution Maintenance Issue Notice Guided Tour (Part 1) Organization and Processes

16 Release Management: Decoupled Concept Development Process DMS1 DMS2 DMS3a DMS3b MS0 MS1 MS2 MS3a MS3b MS4 Part 1 Part 2 Part Part 1 Part 2 Part Incorporation Add technical solution to the documents Concept Assessment Detailing Concept Elaboration Validation Prove maturity of concept Identify inconsistencies & incompleteness Prepare copy-and-paste ready solution based on expert discussions Agree on final technical solution with owner of affected documents Agree on refined use cases and features, concept elements and concept parts Identify affected specifications, new specifications to be created Investigate different solutions, and select the most suitable Prepare project plan and propose validation strategy Evaluate concept (initial technical assessment, dependencies to other concepts) Agree on use cases and features Refine concept request Guided Tour (Part 1) Organization and Processes

17 Achievements new concepts in release For the Basic Software and Methodology Release new concepts were developed and integrated: Communication Enhanced Ethernet Support Switch Configuration Sender Receiver Serialization CAN FD Safety & Security E2E Extension ASIL QM Protection Secure On Board Communication Basic Software NV Data Handling RTE EcuM Fixed MC Methodology Safety Extensions Decentralized Configuration 17 October 22, th Open Conference

18 Organization Overview Project Organization Executive Board Technical Manager Administration Steering Committee Project Leader Team Work Packages Communication Team Legal Team Quality Manager Change Manager Quality Assurance Release Manager Support Functions Technical Office Core Partner Lead WP and WP Subcontractor Regional WPs Guided Tour (Part 1) Organization and Processes

19 Work Package structure from 2015 on Project Leader Team WP-A WP-M WP-I WP-T WP-R-JP Software Architecture WP-A-LIB Libraries WP-A-PRODERR Production Errors WP-A1 VFB and RTE WP-A2 COM Stack Methodology and Templates WP-M-METH Methodology WP-M-GST Generic Structure Template WP-M-SWCT Software Component Template WP-M-SYST System Template ECU Configuration WP-M-TIMEX Timing Extensions Application Interfaces WP-I-BODY Body and Comfort WP-I-ENGINE Powertrain Engine WP-I-TRSM Powertrain Transmission WP-I-CHASSIS Chassis Control WP-I-OCSAFE Occupant and Pedestrian Safety Acceptance Test Japan WP-X-SEC Security WP-X-VAL Validation Cross-product concerns WP-A3 Functional Safety WP-A4 Diagnostics WP-A5 MCAL WP-M1 Timing Analysis Lead Work Package Subgroups Legend: WP-x.y Work Package Subgroups 19 October 22, th Open Conference

20 Overview Motivation and Partnership Organization and Processes Worldwide and other Standards Achievements and Outlook Globalization - motivation and activities Regional co-operations Other Standards Guided Tour (Part 1) Worldwide and other Standards

21 Motivation to Globalize the Organization Foster as a global standard Make the participation for partners in the regions China, India, Japan and US more attractive. That means: Make F2F-Meetings easier Cover local / regional requirements (e.g. provide specific configuration, translations ) Motivate our regional partners to join and support the standardization process Avoid the creation of variants of the standard in the regions started to introduce regional work packages and user groups Guided Tour (Part 1) Worldwide and other Standards

22 Worldwide: Open to Connect Others First activities started At least to be considered Guided Tour (Part 1) Worldwide and other Standards

23 Overview Motivation and Partnership Organization and Processes Worldwide and other Standards Outlook Future of Guided Tour (Part 1) Achievements and Outlook

24 Future of objectives and challenges Maintain stability and compatibility of existing standard. Main directions of the Future of : Reflect new use cases of today s and future market needs. Adapt to upcoming market needs. Support new technologies Anticipate the future identification of technological trends, key features and next challenges for Stabilize the standard maintain the standard, reduce complexity and increase usability, improve job sharing 24 October 22, th Open Conference

25 Starting point selected main drivers Main drivers for new automotive software systems have been determined. Highly automated driving Car-2-X applications Open access to vehicle Stronger interaction 25 October 22, th Open Conference

26 Summary Challenges of a living standard: Improve stability and keep compatibility with existing releases Reflect new use cases of todays and future market needs Main directions of the Future of : Improve existing standard Adapt to upcoming market needs Support new technologies: Car2X, enhanced security, dynamic architectures, June 2014, Munich The Future of

27 Thank you for your attention! More Information about : For information only (see disclaimer) Published Releases Become a partner and get exploitation rights for the standard request@autosar.org Guided Tour (Part 1) Achievements and Outlook

28 Backup 28 11/12/2014 and and Trends in Automotive Software

29 GM SYSTEM/ SOFTWARE PRODUCT LINES BACKUP 29

30 GM NEXT GENERATION TOOLS PROBLEM STATEMENT How do we create a tool set that allows: Full explicit traceability across the development lifecycle in a high reuse, multideployment Product Line Modern Architecture Management Methods Information hiding, component based software engineering, generated middleware, Global large scale multi-user collaboration (~3000 users) Ease of use Minimization of CM version conflict (avoid merges) 30

31 WHAT IS A PRODUCT LINE A Product Line is a set of systems sharing a common, managed set of features that are developed from a common set of core assets in a prescribed way Why Product Line over Products Our Experience As much as an 85% reduction in effort for a second application As much as a 70% reduction in field claims

32 SYSTEM ENGINEERING DEVELOPMENT LIFECYCLE ELECTRICAL Functional Architecture Implementation Architecture Deployment Architecture Vehicle Application Architecture Architecture Requirements PLE Models Requirements PLE Models Electrical Hierarchy Domain Hierarchy Domain Subsystems Functions Allocate FEs to HW/SW SW Hierarchy Structural Packaging Software, Algorithm Models & Parameter Definition HW Hierarchy Allocate Components to ECUs System Design Model SWC HWC Networks ECU 1 n Networks ECU ECU Controller Development Hardware Connectivity Power & Ground Merge with 3D data for wiring Service Documentation ECU Extracts FE FE FE Logical View Hardware Elements Core Arch Design SYSC System Hierarchy Functional Packaging Allocate SYSCs to ECUs Mechanizations Diagnostic Design Network Design 32 Product Line Engineering System Data Change\ CM Integration Platform (Based on OSLC)

33 AN EFFICIENT MEANS OF PRODUCTION FOR SYSTEMS AND SOFTWARE PRODUCT LINES

34 THE SPL LIFECYCLE FRAMEWORK

35 SYNCHRONOUS CONCERNS IN A SPL SOLUTION Multi-product. Feature-based variation management and automated production line Multi-phase. Product line lifecycle assets, architecture and traceability Multi-baseline. Product line change management and baseline management

36 PLE LIFECYCLE BASED ON A CONFIGURABLE BILL OF FEATURES Stakeholder Requirements User Acceptance Test System Requirements Bill of Features System Integration Test Hardware Subsystem Requirements Software Subsystem Requirements Subsystem Integration Software Test Subsystem Integration Hardware Test Hardware Subsystem Design Software Subsystem Design Software Subsystem Wht Box Test Hardware Subsystem Internal Test Hardware Component Implementation Software Component Implementation Software Unit Test Hardware Component Test ECU Allocation Vehicle Layout

37 Exploring : Hardware independent architecture Yesterday Today Software Application Software Customized Standardized Hardware Hardware 37 23rd October, 2013 The Global Automotive E/E Standard

38 Exploring : Software architecture SW Components Application Layer Middle Ware Runtime Environment Basic Software System Services Memory Services Communication Services I/O Hardware Abstraction Complex Drivers Onboard Device Abstraction Memory Hardware Abstraction Communication Hardware Abstraction Microcontroller Drivers Memory Drivers Communication Drivers I/O Drivers ECU Resources Microcontroller 38 23rd October, 2013 The Global Automotive E/E Standard

39 Exploring : Basic Software Abstraction inside the Infrastructure Architecture Example: Communication Stack CAN Communication Services COM Diagnostic Com. Manager Debugging Generic NM Interface System Services Runtime Environment (RTE) Memory Services Application Layer Communication Services I/O Hardware Abstraction Complex Drivers IPDU Multiplexer PDU Router CAN Transport Protocol J1939 Transport Protocol CAN State Manager CAN NM Onboard Device Abstraction Memory Hardware Abstraction Communication Hardware Abstraction Communication Hardware Abstraction CAN Interface Microcontroller Drivers Memory Drivers Communication I/O Drivers Drivers Microcontroller CAN Transceiver Driver I/O Drivers Driver for ext. CAN ASIC Communication Drivers DIO Driver SPIHandler Driver CAN Driver µc SPI CAN External CAN Controller 39 23rd October, 2013 The Global Automotive E/E Standard

40 Exploring : Application interfaces SW Components Application Software Component Interface Actuator Software Component Interface Sensor Software Component Interface Application Layer Application Software Component Interface Runtime Environment System Services Memory Services Communication Services I/O Hardware Abstraction Complex Drivers Ports implement the interface according to the communication paradigm. Ports are the interaction points of software components. Onboard Device Abstraction Microcontroller Drivers The communication is channeled via the RTE. Memory Hardware Abstraction Memory Drivers Communication Hardware Abstraction Communication Drivers Microcontroller The communication layer in the basic software is not visible at the application I/O Drivers layer rd October, 2013 The Global Automotive E/E Standard

41 Exploring : Application interfaces Example engine speed Occupant Safety Powertrain Seat Belt Reminder Combustion Engine Port Engine Speed The actual rotational speed of the engine crankshaft. Interface Engine Speed 1 Connection to transfer a rotational speed of type N1. Data type N1 [rpm]: Uint16 value with resolution rd October, 2013 The Global Automotive E/E Standard

42 Exploring : Methodology Basic approach Virtual Integration SW-C Descriptions SW-C 1 SW-C 2 SW-C 3... SW-C n Application Layer Virtual Functional Bus Introduction of HW Attributes ECU Descriptions Tools supporting development of software components ECU Description System Constraint Description ECU Configuration ECU I ECU II ECU n SW-C 1 SW-C 2 RTE SW-C 3 RTE... SW-C n RTE BSW BSW BSW System Description Flex Ray Gateway CAN 42 23rd October, 2013 The Global Automotive E/E Standard

43 Exploring : Methodology description templates SW-C 1 Application Layer SW-C 2 SW-C 3... SW-C n description templates SWC description: application software Virtual Functional Bus ECU description: ECU characteristics and configuration ECU I SW-C 1 SW-C 2 ECU II SW-C 3 ECU n SW-C n System description: network and assignment of SWCs to ECUs... enable RTE RTE RTE Basic Software Basic Software Basic Software Tool-based deployment of SWCs to ECUs Flex Ray Gateway CAN 43 23rd October, 2013 The Global Automotive E/E Standard