autosar - cnblogs.com autosar configuration methodology (autosar consortium, 2009a) provides...
TRANSCRIPT
AUTOSAR
Agenda
Why AUTOSAR1
Introduction2
Technical Overview3
Backup4
References5
26 August 20152Liu 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 20153Liu 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 20154Liu 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 20155Liu Xue
Agenda
Why AUTOSAR1
Introduction2
Technical Overview3
Backup4
References5
26 August 20156Liu 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 20157Liu 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 20158Liu 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 20159Liu Xue
Agenda
Why AUTOSAR1
Introduction2
Technical Overview3
Software Component3.1
Virtual Functional Bus3.2
ECU Software Architecture3.3
26 August 201510Liu 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 201511Liu 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 201512Liu Xue
Agenda
Why AUTOSAR1
Introduction2
Technical Overview3
Software Component3.1
Virtual Functional Bus3.2
ECU Software Architecture3.3
26 August 201513Liu 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 201514Liu Xue
Agenda
Why AUTOSAR1
Introduction2
Technical Overview3
Software Component3.1
Virtual Functional Bus3.2
ECU Software Architecture3.3
26 August 201515Liu 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 201516Liu Xue
Communication
26 August 201517Liu Xue
Agenda
Why AUTOSAR1
Introduction2
Technical Overview3
Software Component3.1
Virtual Functional Bus3.2
ECU Software Architecture3.3
26 August 201518Liu Xue
The AUTOSAR Methodology3.4
Acceptance Tests3.5
Backup4
References5
Software Architecture
26 August 201519Liu Xue
AUTOSAR Software Components that are mapped on the ECU.
AUTOSAR Software
26 August 201520Liu 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 201521Liu 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 201522Liu Xue
AUTOSAR Interface
Standardized AUTOSAR Interface
Standardized Interface
Classification of interfaces
26 August 201523Liu Xue
26 August 201524Liu Xue
Agenda
Why AUTOSAR1
Introduction2
Technical Overview3
Software Component3.1
Virtual Functional Bus3.2
ECU Software Architecture3.3
26 August 201525Liu Xue
The AUTOSAR Methodology3.4
Acceptance Tests3.5
Backup4
References5
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
The AUTOSAR Methodology
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 August 201526Liu Xue
Agenda
Why AUTOSAR1
Introduction2
Technical Overview3
Software Component3.1
Virtual Functional Bus3.2
ECU Software Architecture3.3
26 August 201527Liu Xue
The AUTOSAR Methodology3.4
Acceptance Tests3.5
Backup4
References5
Acceptance Tests
AUTOSAR Acceptance Test Specifications (ATS) are system tests (ICC1) specifications with interfaces to the application and the bus.
26 August 201528Liu Xue
Agenda
Why AUTOSAR1
Introduction2
Technical Overview3
Backup4
References5
26 August 201529Liu Xue
AUTOSAR Architecture
26 August 201530Liu Xue
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
Basic Software
The Basic Software layers are further divided into functional groups
for example System, Memory and Communication Services.
26 August 201531Liu Xue
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.
Runtime Environment
26 August 201532Liu Xue
The application layer above the RTE is divided into software components.
All software components are completely ECU-independent.
Application Software
26 August 201533Liu Xue
AUTOSAR Methodology
26 August 201534Liu Xue
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 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.
26 August 201535Liu Xue
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 inorder 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 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.
26 August 201536Liu Xue
Configuration parameters
Parameter dependencies
OEM -> ECU extract -> Tier1
Import configuration information files
DBC, LDF, FIBEX, ECU extract of the system description
EB tresos Studio
ECU Configuration
EB tresos Studio
OEM specific default values
26 August 201537Liu Xue
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, 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.
26 August 201538Liu Xue
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.
Functional architecture level
26 August 201539Liu Xue
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.
Physical architecture level
26 August 201540Liu Xue
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.
Application InterfacesSupport Software Sharing
26 August 201541Liu Xue
Roadmap
26 August 201542Liu Xue
Agenda
Why AUTOSAR1
Introduction2
Technical Overview3
Backup4
References5
26 August 201543Liu Xue
Bunzel, Stefan. "Autosar–the standardized software architecture."Informatik-Spektrum 34.1 (2011): 79-83.
Galla, Th M., and Roman Pallierer. "AUTOSAR–challenges and solutions from a software vendor’s perspective." e & i Elektrotechnik und Informationstechnik 128.6 (2011): 234-239.
AUTOSAR, GbR. "AUTOSAR–Technical Overview V2. 0.1." (2006).
References
26 August 201544Liu Xue
45Liu Xue