Agenda. Why AUTOSAR Introduction Technical Overview Backup References. 26 August 2015 Liu Xue

Transcription

1 AUTOSAR

2 Agenda Why AUTOSAR Introduction Technical Overview Backup References 2

3 Background Initial discussions on the common challenge and objectives were held by BMW, Bosch, Continental, DaimlerChrysler and Volkswagen in August, 2002 and the partners were joined soon afterwards by Siemens VDO. Ford Motor Company joined as a Core Partner in November, Peugeot Citroën Automobiles S.A. and Toyota Motor Corporation joined as Core Partners in December, General Motors became Core Partner in November,

4 Motivation Management of E/E complexity associated with growth in functional scope Flexibility for product modification, upgrade and update Scalability of solutions within and across product lines Improved quality and reliability of E/E systems 4

5 Goals Fulfillment of future vehicle requirements, such as, availability and safety, SW upgrades/ updates and maintainability Increased scalability and flexibility to integrate and transfer functions Higher penetration of "Commercial off the Shelf" SW and HW components across product lines Improved containment of product and process complexity and risk Cost optimization of scalable systems 5

6 Agenda Why AUTOSAR Introduction Technical Overview Backup References 6

7 Key Features Modularity and configurability Definition of a layered basic software architecture for automotive electronic control units in order to encapsulate the HW dependencies Consideration of HW dependent and HW independent SW modules Enable the integration of basic SW modules provided by different suppliers to increase the functional reuse Enable the transferability of functional SW-components within a particular E/E-system at least at the final software linking process Resource optimized configuration of the SW infrastructure of each ECU depending on the function deployment Scalability of the E/E-system across the entire range of vehicle product lines 7

8 Standardized interfaces Standardization of different APIs to separate the AUTOSAR SW layers Facilitate encapsulation of functional SW-components Definition of the data types of SW-components Standardization of interfaces of basic SW modules of the SW infrastructure 8

9 Runtime Environment (RTE) Provision of inter- and intra-ecu communication across all nodes of a vehicle network Located between the functional SW-components and the basic SW-modules All entities connected to the AUTOSAR RTE must comply with the AUTOSAR specification Enables the easy integration of customer specific functional SW-modules Acceptance Tests Standardization of test specifications to test a basic software and RTE implementation with respect to application and bus compatibility 9

10 Agenda Why AUTOSAR Introduction Technical Overview 3.1 Software Component Virtual Functional Bus ECU Software Architecture The AUTOSAR Methodology Acceptance Tests Backup References 10

11 Modularity Modularity of automotive software elements enables tailoring of software according to the individual requirements of electronic control units and their tasks. Scalability Scalability of functions ensures the adaptability of common software modules to different vehicle platforms to prohibit proliferation of software with similar functionality. Transferability Transferability of functions optimizes the use of resources available throughout a vehicle s electronic architecture. Re-usability Re-usability of functions helps to improve product quality and reliability and to reinforce corporate brand image across product lines. 11

12 Standardized Interfaces AUTOSAR Software Components Software Component Description Virtual Functional Bus (VFB) System Constraint and ECU Descriptions Mapping on ECUs Runtime Environment (RTE) Basic Software 12

13 Agenda Why AUTOSAR Introduction Technical Overview 3.1 Software Component Virtual Functional Bus ECU Software Architecture The AUTOSAR Methodology Acceptance Tests Backup References 13

14 Software Component SwComponentTypes Encapsulate the implementation of their functionality and behavior PortPrototypes Connection points, exposed to the outside world. In other words, the actual implementation of automotive application software is done by means of the definition of AtomicSwComponentTypes. 14

15 Agenda Why AUTOSAR Introduction Technical Overview 3.1 Software Component Virtual Functional Bus ECU Software Architecture The AUTOSAR Methodology Acceptance Tests Backup References 15

16 Virtual Functional Bus The virtual functional bus is the abstraction of the AUTOSAR Software Components interconnections of the entire vehicle. The communication between different software components and between software components and its environment (e.g. hardware driver, OS, services, etc.) can be specified independently of any underlying hardware. The AUTOSAR Interface concept defines the services or data that are provided on or required by a port of a component. 16

17 Communication 17

18 Agenda Why AUTOSAR Introduction Technical Overview 3.1 Software Component Virtual Functional Bus ECU Software Architecture The AUTOSAR Methodology Acceptance Tests Backup References 18

19 Software Architecture 19

20 AUTOSAR Software AUTOSAR Software Components that are mapped on the ECU. 20

21 AUTOSAR Runtime Environment At system design level, (i.e. when drafting a logical view of the entire system irrespective of hardware) the AUTOSAR Runtime Environment (RTE) acts as a communication center for inter- and intra-ecu information exchange. The RTE provides a communication abstraction to AUTOSAR Software Components attached to it by providing the same interface and services whether inter-ecu communication channels are used (such as CAN, LIN, FlexRay, MOST, etc.) or communication stays intra-ecu. The resulting RTE will differ between one ECU and another. 21

22 AUTOSAR Basic Software Basic Software is the standardized software layer, which provides services to the AUTOSAR Software Components and is necessary to run the functional part of the software. Standardized modules Services. System services such as diagnostic protocols; NVRAM management Communication. Communication Framework (e.g. CAN, LIN, FlexRay...), Network management Operating System. OSEK OS (ISO ) Microcontroller Abstraction. Access to the hardware is routed through the Microcontroller Abstraction Layer (MCAL) to avoid direct access to microcontroller registers from higherlevel software. ECU specific components are: ECU Abstraction. The ECU Abstraction provides a software interface to the electrical values of any specific ECU in order to decouple higher-level software from all underlying hardware dependencies. Complex Driver (CDD). The CDD allows a direct access to the hardware in particular for resource critical applications. 22

23 Classification of interfaces AUTOSAR Interface Standardized AUTOSAR Interface Standardized Interface 23

24 24

25 Agenda Why AUTOSAR Introduction Technical Overview 3.1 Software Component Virtual Functional Bus ECU Software Architecture The AUTOSAR Methodology Acceptance Tests Backup References 25

26 The AUTOSAR Methodology System Configuration Description: includes all system information and the information that must be agreed between different ECUs System Configuration Extractor: extracts the information from the System Configuration Description needed for a specific ECU ECU extract: is the information from the System Configuration Description needed for a specific ECU ECU Configuration Description: contains all basic software configuration information that is local to a specific ECU. The executable software can be built from this information, the code of the basic software modules and the code of the software components 26

27 Agenda Why AUTOSAR Introduction Technical Overview 3.1 Software Component Virtual Functional Bus ECU Software Architecture The AUTOSAR Methodology Acceptance Tests Backup References 27

28 Acceptance Tests AUTOSAR Acceptance Test Specifications (ATS) are system tests (ICC1) specifications with interfaces to the application and the bus. 28

29 Agenda Why AUTOSAR Introduction Technical Overview Backup References 29

30 AUTOSAR Architecture 30

31 Basic Software The AUTOSAR Basic Software is divided into the following BSW layers: Services, ECU abstraction, microcontroller abstraction, and complex drivers. The Basic Software layers are further divided into functional groups for example System, Memory and Communication Services. 31

32 Runtime Environment The Runtime Environment abstracts the application layer from the basic software and organizes the data and information traffic between them. The defined transfer interfaces of the RTE allow application software components to be developed without specific knowledge of what hardware will be used later. 32

33 Application Software The application layer above the RTE is divided into software components. All software components are completely ECU-independent. 33

34 AUTOSAR Methodology 34

35 The AUTOSAR configuration methodology (AUTOSAR Consortium, 2009a) provides system-wide and ECU-specific configuration parameters and standardized XML-based exchange formats. The AUTOSAR methodology describes the major development steps of an overall AUTOSAR system, which means the entire software for a network of interconnected ECUs in a vehicle. It addresses the wide range of software development from the system-level configuration to the generation of an ECU executable, and it supports a widely decoupled development and implementation of application functionality, as well as a seamless integration and configuration of both, the overall system and its individual ECUs. This configuration methodology allows to clearly separate the configuration tasks between OEM (system configuration) and Tier1 (ECU configuration) and enable both system-wide and ECU-specific optimizations. 35

36 EBtresos Studio is an universal configuration tool for all these basic software modules and the Rte. This tool can import an AUTOSAR system description or ECU extract of the system description and convert it into the corresponding ECU configuration parameters in order to configure all AUTOSAR basic software modules and the Rte for a specific ECU. AUTOSAR stack from software vendors, like Elektrobit (EB) Basic software stacks A working basic software stack consisting of over 80 basic software modules (AUTOSAR Consortium, 2009c) that make up the AUTOSAR software architecture. 36

37 ECU Configuration Configuration parameters Parameter dependencies OEM -> ECU extract -> Tier1 Import configuration information files DBC, LDF, FIBEX, ECU extract of the system description EB tresos Studio OEM specific default values 37

38 In addition to the over 80 software modules and libraries specified by AUTOSAR, each OEM has a certain number of legacy modules that need to be integrated into the AUTOSAR basic software stack. OEMs and Tier1s introducing this powerful technology, however, have to master some main challenges, such as considering all OEM specific requirements, handling the configuration complexity, optimal usage of restricted hardware resources, and the integration of existing legacy modules. Software vendors such as EB working closely together with OEMs, can provide Tier1s with powerful configuration tools and AUTOSAR basic software stack implementations that fulfill all these requirements. 38

39 Functional architecture level The functional architecture level deals with the Virtual Functional Bus (VFB) which enables the development of the functional architecture of the entire system independent from the actual hardware topology of ECUs and the network. 39

40 Physical architecture level the activity design system leads to a system description that defines the system topology of ECUs, the network, and the mapping of components to ECUs. Before the software for each ECU can be built, the information regarding this ECU has to be extracted from the system description. The development of the application software components with the definition of the internal behavior, coding, and implementation are independent from hardware and can be done separately for each component. 40

41 Application Interfaces Support Software Sharing AUTOSAR supports software sharing by providing architecture, infrastructure, methodology, and the basic software. In addition, standardized application interfaces support the exchangeability of software between suppliers. 41

42 Roadmap 42

43 Agenda Why AUTOSAR Introduction Technical Overview Backup References 43

44 References Bunzel, Stefan. "Autosar the standardized software architecture."informatik- Spektrum 34.1 (2011): Galla, Th M., and Roman Pallierer. "AUTOSAR challenges and solutions from a software vendor s perspective." e & i Elektrotechnik und Informationstechnik (2011): AUTOSAR, GbR. "AUTOSAR Technical Overview V " (2006). 44

45 45