1.1 Introduction
AUTOSAR（汽車開放系統架構）是一個開放的，標准化的汽車軟件架構，由汽車制造商，供應商和開發工具共同開發。它聯合了汽車OEM ，供應商和開發工具供應商，其目標是創建並建立開放標准為汽車E / E（電子/電器）架構。它將為所有應用程序領域提供一個基本的基礎設施以幫助開發汽車軟件，用戶界面和管理。這包括基本的系統功能的標准化，可擴展性，不同的車輛和平台的變種，轉移性整個網絡，整合來自多個供應商，可維護性在整個產品生命周期和軟件的更新和升級在車輛的生命周期。[2]
1.2. Vision
- 軟件和硬件分離
- 開發可以在平行層de-coupled，減少開發時間和成本
- 軟件復用率會提高，OEM和供應商
1.3.
沒有中國廠商。
1.2. Key Features
Modularity and configurability
Standardized interfaces
Runtime Environment (RTE)
Acceptance Tests
2. Goals
As stated in the official website, the goals of AUTOSAR are:
- Implementation and standardization of basic system functions as an OEM wide "Standard Core" solution
- Scalability to different vehicle and platform variants
- Transferability of functions throughout network
- Integration of functional modules from multiple suppliers
- Consideration of availability and safety requirements
- Redundancy activation
- Maintainability throughout the whole "Product Life Cycle"
- Increased use of "Commercial off the shelf hardware"
- Software updates and upgrades over vehicle lifetime
3. Technical Overview
AUTOSAR Architecture
AUTOSAR architecture支持完整的軟件和硬件模塊的獨立性(Independence)。軟件包括三層：Application SW, Runtime Environment, 和Basic SW. [3]
3.1. Software Component
AUTOSAR的軟件被組織在獨立單位里面，software-component,或者SwComponentTypes。
SwComponentTypes封裝它們的功能和行為，只向外界開放定義好的鏈接點，稱為PortPrototypes。
3.2. Virtual Functional Bus
In order to fulfill the goal of transferability, AUTOSAR defines a layered SW architecture and a formal description language for Software Components so that these components can be implemented independently from the underlying hardware.
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 central structural element in AUTOSAR is the COMPONENT. A component has well-defined ports, through which it interacts with other components. A port always belongs to exactly one component. The AUTOSAR Interface concept defines the services or data that are provided on or required by a port of a component. The most commonly used AUTOSAR Interfaces are Client-Server Interfaces (defining a set of operations that can be invoked) and Sender-Receiver Interfaces, which allows the usage of data-oriented communication mechanisms over the VFB. Other kinds of interfaces allow the communication of modes, non-volatile or fixed data, and the triggering of processes.
Client-Server Communication
Sender-Receiver Communication
3.3. ECU Software Architecture
The structure of the software for an ECU. The layers and its main elements.
- AUTOSAR Software
The AUTOSAR Software (the layer above AUTOSAR Runtime Environment) consists of AUTOSAR Software Components that are mapped on the ECU. All interaction between AUTOSAR Software Components and Atomic Software Components is routed through the AUTOSAR Runtime Environment. The AUTOSAR Interface assures the connectivity of software elements surrounding the AUTOSAR Runtime Environment.
- 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.
Inter-ECU communication: CAN, LIN, FlexRay, MOST, etc.
- 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. It does not fulfill any functional job itself and is situated below the AUTOSAR Runtime Environment.
Standardized modules: Services, Communication, Operating System, Microcontroller Abstraction
ECU specific modules: ECU Abstraction, Complex Driver
- Classification of interface
AUTOSAR Interface
Standardized AUTOSAR Interface
Standardized Interface
3.4. 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
3.5. Acceptance Tests
4. RoadMap
References:
1. AUTOSAR, GbR. "Technical Overview." document version 2.0 (2008).
2. AUTOSAR Wike, https://en.wikipedia.org/wiki/AUTOSAR
3. AUTOSAR Layered Software Architecture, R4.0. http://www.autosar.org/
download/R4.0/AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf, last access
16.11.2010
4. Bunzel, Stefan. "Autosar–the standardized software architecture."Informatik-Spektrum 34.1 (2011): 79-83.
版權所有，侵權必究，如需使用請與作者本人聯系。