Dr. Stefan Bunzel AUTOSAR Spokesperson (Continental) 8. Workshop Automotive Software Engineering 30 September, 2010, Leipzig

Transcription

1 Hardware-independent Development with Dr. Stefan Bunzel Spokesperson (Continental) 8. Workshop Automotive Engineering, Leipzig

2 Overview Introduction to Overview on Architecture Development Methodology 2 Hardware-independent Development with

3 Vision aims to improve complexity management of integrated E/E architectures through increased reuse and exchangeability of SW modules between OEMs and suppliers. OEM b OEM a Platform b.1 Platform b.2 Platform b.n Exchangeability between suppliers OEM c solutions Platform a.1 Platform a.2 Platform a.n Exchangeability between manufacturers applications OEM f Platform f.1 Platform f.2 Platform f.n Supplier A Chassis Safety Body/ Comfort OEM e Supplier C Platform e.1 Platform e.2 Platform e.n Supplier B Chassis Safety Telematics Body/Comfort Powertrain Telematics Platform c.1 Platform c.2 Platform c.n OEM d Platform d.1 Platform d.2 Platform d.n Exchangeability between vehicle platforms 3 Hardware-independent Development with

4 Vision aims to standardize the software architecture of s. paves the way for innovative electronic systems that further improve performance, safety and environmental friendliness. Yesterday Hardware Application Hardware standardized HW-specific Customer needs Adaptive Cruise Control Lane Departure Warning Advanced Front Lighting System Using standards Communication Stack OSEK Diagnostics CAN, FlexRay Hardware and software will be widely independent of each other. Development can be de-coupled by horizontal layers. This reduces development time and costs. The reuse of software increases at OEM as well as at suppliers. This enhances quality and efficiency. 4 Hardware-independent Development with

5 Core Partners and Members 9 Core Partners 11 Development Members 47 Premium Members 63 Associate Members 6 Attendees General OEM Generic Tier 1 Standard Tools and Services Semiconductors Status 22 September Up-to-date status see: 5 Hardware-independent Development with

6 9 Project Objectives and 3 Main Working Topics PO1: Implementation and standardization of basic system functions as an OEM wide Standard Core solution PO2: Scalability to different vehicle and platform variants PO3: Transferability of functions throughout network PO4: Integration of functional modules from multiple suppliers Application s Architecture Methodology PO5: Maintainability throughout the whole Product Life Cycle PO6: Increased use of Commercial off the shelf hardware PO7: updates and upgrades over vehicle lifetime PO8: Consideration of availability and safety requirements PO9: Redundancy activation 6 Hardware-independent Development with

7 Specifications vs. Products Core Partners, Premium, and Development Members Develop compliant products SW modules Tools s Cars Members Partnership Cooperate on standards, compete on implementation. Standard Specifications Architecture Methodology Appl. s Releases R4.0, R3.2, R3.1, Build Apply 7 Core Partners, Premium, Development, and Associate Members Hardware-independent Development with

8 Overview Introduction to Overview on Architecture Development Methodology 8 Hardware-independent Development with

9 Layered Architecture Application Layer Runtime Environment (RTE) BSW-Layers System Services Memory Services Communication Services I/O Hardware Complex Services Onboard Device Memory Hardware Comm. Hardware and Complex Microcontroller Memory Communication I/O Microcontroller Microcontroller 10 Hardware-independent Development with

10 inside the Infrastructure Architecture Example: Memory stack Equal mechanisms to access internal (on-chip) and external (on-board) memory devices and type of memory hardware (EEPROM, Flash) Abstracts from the location of peripheral memory devices (on-chip or on-board) and the hardware layout. Memory Services NVRAM Manager Application Layer System Services Runtime Environment (RTE) Memory Services Communication Services I/O Hardware Complex Memory Hardware Memory Onboard Device Memory Hardware Communication Hardware EEPROM Flash EEPROM Emulation Microcontroller Memory Communication I/O Microcontroller External EEPROM Driver COM SPIHandler Driver EEPROM Driver External Flash Driver Memory Internal Flash Driver SPI µc EEPROM Flash 11 Hardware-independent Development with

11 inside the Infrastructure Architecture Example: CAN communication stack CAN Communication Services provide a uniform interface to the CAN network. Hide protocol and message properties from the application. Application Layer Runtime Environment (RTE) IPDU Multiplexer COM Communication Services Diagnostic Com. Manager PDU Router CAN Transport Protocol Debugging J1939 Transport Protocol CAN State Manager Generic NM CAN NM System Services Memory Services Communication Services I/O Hardware Complex Communication Hardware Onboard Device Memory Hardware Communication Hardware CAN Microcontroller Memory Communication I/O CAN Transceiver Driver Driver for ext. CAN ASIC Microcontroller I/O DIO Driver SPIHandler Driver Communication CAN Driver µc SPI CAN External CAN Controller 12 Hardware-independent Development with

12 Overview Introduction to Overview on Architecture Development Methodology 13 Hardware-independent Development with

13 Architecture Layered Architecture Application Layer Breakdown to / Implementation on Runtime Environment (RTE) Services Layer Layer Microcontroller Layer Hardware Complex Application Architecture Actuator Sensor Componen t... Application Componen t Runtime Environment Operating System Services Basic Communication Microcontr. Complex Device -Hardware 14 Hardware-independent Development with

14 Development Methodology Virtual Functional Bus Concept Virtual Functional Bus n Application software functionality implemented in s () Handling of vehicle wide functions, independent from s or network s can communicate between each other and access functions from the standardized set of infrastructure functions Communication needs of a are formally described in a standard template, i.e. the Any interaction runs via Ports, which implement different communication paradigms, e.g. sender-receiver or client-server The VFB enables a virtual integration of s and allows to formally verify structural and dynamic compatibility of s 15 Hardware-independent Development with

15 Development Methodology Virtual Functional Bus Concept Ports and s PPort, provides a Sender-Receiver RPort, requires a Sender-Receiver PPort, provides a Client-Server, i.e. implements service n RPort, requires a Client-Server, i.e. client of a service PPort, provides a Calibration RPort, requires a Calibration PPort, provides data to Service RPort, requires data from Service Virtual Functional Bus PPort, provides Service (in BSW only) RPort, requires Service as client 16 Hardware-independent Development with

16 Development Methodology Principle I 1 1 RTE Basic Virtual Functional Bus 3 II 2 RTE Basic... n m n RTE Basic description templates: description: application software description: characteristics and configuration System description: network and assignment of s to s s for s + s + system description allow a tool-based deployment of s to s FlexRay Gateway CAN System 17 Hardware-independent Development with

17 Development Methodology Development steps From functional level to the binaries. Functional architecture level modeling Data model development VFB Timing Develop VFB System Physical architecture level Design System System topology Network Mapping of components to s Internal behavior Implementation timing Develop Application BSW implementation Configuration Deliver Basic Generate Extract Build Hardware dependent Hardware independent 18 Hardware-independent Development with

18 Methodology and Templates Overview The Methodology provides all descriptions necessary to describe all components of a system.. System Level Work product, e.g. XML-, C-, or binary file.xml.xml Activity, consuming or producing a work product System Constraints Configure System System Configuration Object flow, input to or produced by activities Referencing, using, or reading work products.xml Extract -Specific Information.XML Level.XML. exe related templates Extract of System Configuration Configure Configuration Generate Executable Executable Level.XML.XML Implement Implemented 19 Hardware-independent Development with

19 Methodology and Templates RTE Generation Process x 1 3 RTE Basic 20 Hardware-independent Development with

20 Application s Above the RTE the software architecture style changes from layered to component style., openly disclosed interfaces HW independent SW layer Transferability of functions Application Layer RTE Services Layer Layer Layer Microcontroller Layer Microcontroller Complex Application Actuator Sensor Sensor Application Layer Application 21 Hardware-independent Development with

21 Development Methodology Application s R4.0 Specification: Table of Application s Mirror Adjustment MirrorPosition MirrorMoveStatus MirrPosnSts1 Records Continuous Values Enumerations Arrays m sec Percent 40 Compositions 2500 Ports 570 s 770 Data types 26 Units Mirror Adjustment MirrPosnSts1 MirrAxisPosn1 Mirror type Axis type Position Enumeration 0: no axis 1: horizontal axis 2: vertical axis Continuous Value: perc7 Recommended type: UInt14 Unit: Percent Range: 0, ,0 Resolution: 0,1 22 Hardware-independent Development with

22 Application s Re-Use of SW-s To ease the re-use of software components across several OEMs, proceeds on the standardization of application interfaces. 2nd Yaw Rate Controller Example Base Sensor Signals Ínterface of ESP and external yaw rate controller I 6 System-level Brake Actuator I 7 ESP-Sensors I 1 ESP SW- Brake Actuator of ESP and VLC I 4 I 2 I 3 I 5 Vehicle Longitudinal Controller Standard Signals from ESP Information signals from other functions / domains Command signals to other functions / domains application interfaces on system level (ESP-system, chassis domain) Port Name Port Name Appl. Remarks Port Name LongAccBase YawRateBase Yaw rate measured along vehicle z- axis (i.e. compensated for orientation). Coordinate sys. according to ISO YawRate1 Data element: YawRate Data Type: AngleSpeed3 Minimal bits size: SInt16 Physical Range: -5,..+5, Physical offset: 0 Unit: rad/sec. This data element can also be used to instantiate a redundant sensor interface. Range might have to be extended for future applications (passive safety). RollRateBase 23 Hardware-independent Development with

23 Architecture Defined s Use Case Front Light Management mapped to architecture Integrator Supplier B OEM Supplier A SwitchEvent check_switch () switch_event (event) Int. LightRequest switch_event(event) request_light (type, mode) Front-Light Manager request_light(type, mode) get_keyposition() set_light(type, mode) set_dboard(type, mode) RTE Headlight set_light(type, mode) set_current ( ) Silicon vendor A Integrator Operating System Std. Services Std. DIO Communication Std. PWM Microcontroller -Hardware Std. CAN Driver Complex Device 24 Hardware-independent Development with

24 Architecture Defined s Use Case Front Light Management : Exchange type of Front Light Integrator Supplier B OEM Supplier CA SwitchEvent check_switch () switch_event (event) Int. LightRequest switch_event(event) request_light (type, mode) Front-Light Manager request_light(type, mode) get_keyposition() set_light(type, mode) set_dboard(type, mode) RTE Xenonlight Headlight set_light(type, mode) set_current ( ) Silicon vendor B A Integrator Operating System Std. Services Std. DIO Communication Std. PWM DIO Microcontroller -Hardware Std. CAN Driver Complex Device 25 Hardware-independent Development with

25 Application s Supplier Use Case Specification of application interfaces will support integration of SW-components. OEM_1 s interfaces specifications integrate several application interfaces.xml OEM_2 s interfaces specifications integrate several application interfaces.xml OEM_N s interfaces specifications integrate several application interfaces.xml Application Actuator Sensor Application Runtime Environment (RTE) X.y Services Communication... Supplier container s Model and implement only once Operating System Inteface Basic -Hardware Microcontroller Complex Device Use of application interfaces increase quality on integration, i.e. they prevent from inconsistencies. 26 Hardware-independent Development with

26 Summary has become a global standard for embedded automotive software, providing specifications for architecture Development methodology application interfaces Layered software architecture Hardware-independent development of application functions AR 1 AR 2 AR 3... Virtual Functional Bus AR n Early virtual integration of the entire vehicles application functions is a key enabler for managing the growing E/E complexity First series cars with technology are on the road 27 Hardware-independent Development with

27 Thank you for your attention! Become a member and get exploitation rights for the standard. Published Releases For information only, see disclaimer. 28 Hardware-independent Development with