Automotive Security的一些资料和心得（6）：AUTOSAR

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.

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.

 

版权所有，侵权必究，如需使用请与作者本人联系。