Automotive Security的一些资料和心得(6):AUTOSAR
2015-08-12 09:19
651 查看
1.1 Introduction
AUTOSAR(汽车开放系统架构)是一个开放的,标准化的汽车软件架构,由汽车制造商,供应商和开发工具共同开发。它联合了汽车OEM ,供应商和开发工具供应商,其目标是创建并建立开放标准为汽车E / E(电子/电器)架构。它将为所有应用程序领域提供一个基本的基础设施以帮助开发汽车软件,用户界面和管理。这包括基本的系统功能的标准化,可扩展性,不同的车辆和平台的变种,转移性整个网络,整合来自多个供应商,可维护性在整个产品生命周期和软件的更新和升级在车辆的生命周期。[2]
1.2. Vision
![](https://oscdn.geek-share.com/Uploads/Images/Content/202003/21/49e6f9f7671c66124737c5c27b4481c4.png)
软件和硬件分离
开发可以在平行层de-coupled,减少开发时间和成本
软件复用率会提高,OEM和供应商
1.3.
![](https://oscdn.geek-share.com/Uploads/Images/Content/202003/21/1b5cb987236ed0597c1ecfa786dc0078.png)
没有中国厂商。
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
![](https://oscdn.geek-share.com/Uploads/Images/Content/202003/21/d4b5c144408705b8b68cff3d02eb917d.jpg)
AUTOSAR Architecture
AUTOSAR architecture支持完整的软件和硬件模块的独立性(Independence)。软件包括三层:Application SW, Runtime Environment, 和Basic SW. [3]
![](https://oscdn.geek-share.com/Uploads/Images/Content/202003/21/d34d16d80d45fb45c7659d06788ccdbd.png)
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.
![](https://oscdn.geek-share.com/Uploads/Images/Content/202003/21/acb36db034e41117106a7216b4a30bb4.jpg)
- 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
![](https://oscdn.geek-share.com/Uploads/Images/Content/202003/21/5d52914a670ff5cc3d53e08a0732d2c1.jpg)
![](https://oscdn.geek-share.com/Uploads/Images/Content/202003/21/27d32ae0eaa77cfcb96071e47b488e9a.png)
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
![](https://oscdn.geek-share.com/Uploads/Images/Content/202003/21/74d9820f7de672917ff7610c613a79df.jpg)
4. RoadMap
![](https://oscdn.geek-share.com/Uploads/Images/Content/202003/21/2dcfc72a53c68090e294c947bb83b734.png)
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.
5. 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(汽车开放系统架构)是一个开放的,标准化的汽车软件架构,由汽车制造商,供应商和开发工具共同开发。它联合了汽车OEM ,供应商和开发工具供应商,其目标是创建并建立开放标准为汽车E / E(电子/电器)架构。它将为所有应用程序领域提供一个基本的基础设施以帮助开发汽车软件,用户界面和管理。这包括基本的系统功能的标准化,可扩展性,不同的车辆和平台的变种,转移性整个网络,整合来自多个供应商,可维护性在整个产品生命周期和软件的更新和升级在车辆的生命周期。[2]
1.2. Vision
![](https://oscdn.geek-share.com/Uploads/Images/Content/202003/21/49e6f9f7671c66124737c5c27b4481c4.png)
软件和硬件分离
开发可以在平行层de-coupled,减少开发时间和成本
软件复用率会提高,OEM和供应商
1.3.
![](https://oscdn.geek-share.com/Uploads/Images/Content/202003/21/1b5cb987236ed0597c1ecfa786dc0078.png)
没有中国厂商。
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
![](https://oscdn.geek-share.com/Uploads/Images/Content/202003/21/d4b5c144408705b8b68cff3d02eb917d.jpg)
AUTOSAR Architecture
AUTOSAR architecture支持完整的软件和硬件模块的独立性(Independence)。软件包括三层:Application SW, Runtime Environment, 和Basic SW. [3]
![](https://oscdn.geek-share.com/Uploads/Images/Content/202003/21/d34d16d80d45fb45c7659d06788ccdbd.png)
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.
![](https://oscdn.geek-share.com/Uploads/Images/Content/202003/21/acb36db034e41117106a7216b4a30bb4.jpg)
- 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
![](https://oscdn.geek-share.com/Uploads/Images/Content/202003/21/5d52914a670ff5cc3d53e08a0732d2c1.jpg)
![](https://oscdn.geek-share.com/Uploads/Images/Content/202003/21/27d32ae0eaa77cfcb96071e47b488e9a.png)
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
![](https://oscdn.geek-share.com/Uploads/Images/Content/202003/21/74d9820f7de672917ff7610c613a79df.jpg)
4. RoadMap
![](https://oscdn.geek-share.com/Uploads/Images/Content/202003/21/2dcfc72a53c68090e294c947bb83b734.png)
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.
5. 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.
版权所有,侵权必究,如需使用请与作者本人联系。
相关文章推荐
- 简单返回顶部代码及注释说明
- mysql_insert_id()寻找上一次插入的id
- PDF之itextsharp的使用开发历程3
- poj-3349-Snowflake Snow Snowflakes-哈希
- 关于多态的一些自己理解
- buffer和cache的区别
- 笔记
- 常用的正则表达式资料整理
- nginx与Apache的优缺点
- 使用NSURLConnection发送http网络请求
- ionic 项目中添加modal的步骤流程
- 获取访问者的真实IP地址,绕过路由映射等
- ios开发(plist文件数据加载) 使用数据模型的方法加载plist文件中的数据
- 黑马程序员——Java基础多态、内部类、异常
- 程序员如何持续提升自己的开发技能
- requirejs 跨域
- android 中Dialog的一些用法
- wpf GridSplitter
- 下拉框选中一个选项后 触发事件
- php session/完整判断是否https/对象与数组互转/文件下载