autosar - autosar configuration methodology (autosar consortium, 2009a) provides system-wide and...

Download AUTOSAR - AUTOSAR configuration methodology (AUTOSAR Consortium, 2009a) provides system-wide and ECU-specific

Post on 10-Apr-2020

5 views

Category:

Documents

1 download

Embed Size (px)

TRANSCRIPT

  • AUTOSAR

  • Agenda

    Why AUTOSAR1

    Introduction2

    Technical Overview3

    Backup4

    References5

    26 August 2015 2Liu Xue

  •  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, 2003.

     Peugeot Citroën Automobiles S.A. and Toyota Motor Corporation joined as Core Partners in December, 2003.

     General Motors became Core Partner in November, 2004.

    Background

     General Motors became Core Partner in November, 2004.

    26 August 2015 3Liu Xue

  •  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

    Motivation

    26 August 2015 4Liu Xue

  •  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

    Goals

     Cost optimization of scalable systems

    26 August 2015 5Liu Xue

  • Agenda

    Why AUTOSAR1

    Introduction2

    Technical Overview3

    Backup4

    References5

    26 August 2015 6Liu Xue

  • 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

    Key Features

     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

    26 August 2015 7Liu Xue

  • 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

    26 August 2015 8Liu Xue

  • 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

    26 August 2015 9Liu Xue

  • Agenda

    Why AUTOSAR1

    Introduction2

    Technical Overview3

    Software Component3.1

    Virtual Functional Bus3.2

    ECU Software Architecture3.3

    26 August 2015 10Liu Xue

    The AUTOSAR Methodology3.4

    Acceptance Tests3.5

    Backup4

    References5

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

    26 August 2015 11Liu Xue

  •  AUTOSAR Software Components

     Software Component Description

     Virtual Functional Bus (VFB)

     System Constraint and ECU Descriptions

     Mapping on ECUs

    Standardized Interfaces

     Runtime Environment (RTE)

     Basic Software

    26 August 2015 12Liu Xue

  • Agenda

    Why AUTOSAR1

    Introduction2

    Technical Overview3

    Software Component3.1

    Virtual Functional Bus3.2

    ECU Software Architecture3.3

    26 August 2015 13Liu Xue

    The AUTOSAR Methodology3.4

    Acceptance Tests3.5

    Backup4

    References5

  • SwComponentTypes

     Encapsulate the implementation of their functionality and behavior

    PortPrototypes

     Connection points, exposed to the outside world.

    Software Component

    In other words, the actual implementation of automotive application software is done by means of the definition of AtomicSwComponentTypes.

    26 August 2015 14Liu Xue

  • Agenda

    Why AUTOSAR1

    Introduction2

    Technical Overview3

    Software Component3.1

    Virtual Functional Bus3.2

    ECU Software Architecture3.3

    26 August 2015 15Liu Xue

    The AUTOSAR Methodology3.4

    Acceptance Tests3.5

    Backup4

    References5

  •  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.)

    Virtual Functional Bus

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

    26 August 2015 16Liu Xue

  • Communication

    26 August 2015 17Liu Xue

  • Agenda

    Why AUTOSAR1

    Introduction2

    Technical Overview3

    Software Component3.1

    Virtual Functional Bus3.2

    ECU Software Architecture3.3

    26 August 2015 18Liu Xue

    The AUTOSAR Methodology3.4

    Acceptance Tests3.5

    Backup4

    References5

  • Software Architecture

    26 August 2015 19Liu Xue

  •  AUTOSAR Software Components that are mapped on the ECU.

    AUTOSAR Software

    26 August 2015 20Liu Xue

  •  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.

    AUTOSAR Runtime Environment

     The resulting RTE will differ between one ECU and another.

    26 August 2015 21Liu Xue

  •  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 17356-3)

     Microcontroller Abstraction. Access to the hardware is routed through the Microcontroller

    AUTOSAR Basic Software

     Microcontroller Abstraction. Access to the hardware is routed through the Microcontroller Abstraction Layer (MCAL) to avoid direct access to microcontroller registers from higher- level 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.

    26 August 2015 22Liu Xue

  •  AUTOSAR Interface

     Standardized AUTOSAR Interface

     Standardized Interface

    Classification of interfaces

    26 August 2015 23Liu Xue

  • 26 August 2015 24Liu Xue

  • Agenda

    Why AUTOSAR1

    Introduction2

    Technical Overview3

    Software Component3.1

    Virtual Functional Bus3.2

    ECU Software Architecture3.3

    26 August 2015 25Liu Xue

    The AUTOSAR Methodology3.4

    Accepta

Recommended

View more >