小柴带你学AutoSar系列三、标准和规范篇（1）General

flechazo

小柴冲刺嵌入式系统设计师系列总目录

小柴带你学AutoSar总目录

缘起

一个小小的介绍啦，逐字逐句读规范。😜

不求能记住多少❤️

只是希望将知识串起来，用到的时候能快速找到就好啦！

一起学习AUTOSAR的规范吧

下面呢分为几个部分带着大家读一下规范啦

缘起

一、Features特性

System and Architecture

Operating System

Runtime Environment (RTE)

Services

Mode Management

Communication via Bus

Communication buses

Memory Stack

Microcontroller Abstraction and I/O

Security

Safety

Libraries

Diagnostic and Error Handling

Test and Debugging

Integration and Migration

Standardization and Documentation

二、VFB虚拟功能总线

1 Introduction to this document

1.1 Contents

1.3 Relationship to other AUTOSAR specifications

1.4 Structure and conventions of this document

2 The Virtual Functional Bus

这里可以看到VFB的作用

VFB是这些组件的交互机制

RTE将组件与组件之间和组件与BSW之间分离，不再依赖。实现软件组件的独立。

VFB提供以下概念：

3 Overall mechanisms and concepts

3.1 Components

3.2 Port-Interfaces接口

3.3 Ports

3.3.1 Port Types

3.3.2 Port Compatibility

3.3.3 Data Type Policies

3.4 Connectors

3.4.1 Unconnected Ports

3.5 Compositions versus atomic components

3.6 Relationship between the VFB and the ECU Software Architecture

3.7 Kinds of software components

三、BulkNvDataManager

1 Introduction and functional overview

7 Functional specification

四、SecurityOverview

Attacks and Countermeasures

Existing Solutions

Write xor Execute, Data Execution Prevention (DEP)

Stack Smashing Protection (SSP)

Address Space Layout Randomization (ASLR)

Control-flow Integrity (CFI)

Code Pointer Integrity (CPI), Code Pointer Separation (CPS)

Pointer Authentication

Horizontal Isolation

五、SafetyOverview

总览

Vehicle Context

ECU Context

Microprocessor Context

Potential Hardware Faults and Safety Measures

Potential Software Faults and Safety Measures

一、Features特性

System and Architecture

4.1.1 [RS_BRF_01000] AUTOSAR architecture shall organize the BSW in a hardware independent and a hardware dependent layer

硬件抽象，需要脱离硬件的依赖哦

4.1.2 [RS_BRF_01008] AUTOSAR shall organize the hardware dependent layer in a microcontroller independent and a microcontrollerdependent layer

将独立的mcu和需要相互依赖的mcu分为两层

4.1.3 [RS_BRF_01016] AUTOSAR shall provide a modular design inside software layers

高内聚，低耦合

4.1.4 [RS_BRF_01024] AUTOSAR shall provide naming rules for public symbols

命名要有规范

4.1.5 [RS_BRF_01028] AUTOSAR shall provide naming conventions for symbols in its documentation

命名要有规范

4.1.6 [RS_BRF_01032] AUTOSAR modules shall provide meta data information

提供代码的版本信息，与适配工具的版本信息，适配相应版本的工具。版本不匹配报错

4.1.7 [RS_BRF_01040] AUTOSAR shall allow multiple instantiation of Basic Software Modules where appropriate

每个模块都允许多个实例化，就是用数组去控制，可以存在多个不同配置的模块

4.1.8 [RS_BRF_01048] AUTOSAR module design shall support modules to cooperate in a multitasking environment

应该考虑多任务的环境，及代码的重入性。以及其他模块对资源的占用。

4.1.9 [RS_BRF_01056] AUTOSAR BSW modules shall provide standardized interfaces

模块提供统一的对外接口，对外函数要标准要统一风格

4.1.10 [RS_BRF_01064] AUTOSAR BSW shall provide callback functions in order to access upper layer modules

通过提供回调函数来给上层调用者提供函数支持或状态提醒

4.1.11 [RS_BRF_01072] AUTOSAR BSW shall provide callout functions in order to implement certain functionality in integrator code

提供一些钩子函数，触发某种状态会调用callout。例如 shutdown的hook

4.1.12 [RS_BRF_01076] AUTOSAR basic software shall perform module local error recovery to the extent possible

要有报错机制

4.1.13 [RS_BRF_01080] AUTOSAR shall allow access to internal and external peripheral devices

将外设映射在地址总线中统一管理。例如将外部存储映射到一个地址去访问。

4.1.14 [RS_BRF_01088] AUTOSAR shall offer interfaces which allow to express high level application communication needs

通信时需要有状态管理，支持部分组网。

4.1.17 [RS_BRF_01112] AUTOSAR shall offer interfaces to boot loader

提供用于bootloader交互的接口

4.1.18 [RS_BRF_01120] AUTOSAR shall support re-flashing of configured BSW data

🥫应该将代码和配置代码分离烧录。在ld链接脚本文件中划分特有的区域存储静态代码和配置。这样可以单独烧录配置代码来改变配置而无需改变已有的静态代码。

4.1.19 [RS_BRF_01136] AUTOSAR shall support variants of configured BSW data resolved after system start-up

将配置项使用宏定义作为可选的配置项，来适配不同的配置。使用宏定义来管理不同的变体来初始化不同的行为。

4.1.20 [RS_BRF_01128] AUTOSAR shall allow software components to be started before all BSW modules are initialized

单独组件的初始化不应该依赖于其他组件的初始化。可以使用状态机来管理依赖i项。也就是分批次进行不同级别或者说不同子模块的初始化。

4.1.21 [RS_BRF_01144] AUTOSAR shall support configuration parameter which allow to trade interrupt response time against runtime

其他中断会打断或阻塞这次中断后数据的处理和相应速度，可以将处理放在异步执行的任务中。

4.1.22 [RS_BRF_01152] AUTOSAR shall support limited dynamic reconfiguration

配置中有部分可以动态配置。有部分则不可以。

4.1.23 [RS_BRF_00206] AUTOSAR shall support multi-core MCUs

应该支持多核架构

4.1.24 [RS_BRF_01160] AUTOSAR shall support BSW distribution on multi core MCUs

多核应该有自己单独的通信总线，同时多核之间的通信总线也应该有相互的网关

4.1.25 [RS_BRF_01168] AUTOSAR BSW and RTE shall support MCUs with memory write protection

内存写保护

4.1.26 [RS_BRF_00057] AUTOSAR shall define a memory mapping mechanism

内存映射机制

4.1.27 [RS_BRF_01176] The RTE shall be the only interfacing layer between software components and the BSW

RTE是SWC和BSW之间的唯一接口

4.1.28 [RS_BRF_01184] AUTOSAR shall support different methods of degradation

需要支持init和deinit，支持部分方法或者模式的部分初始化

Operating System

4.2.1 [RS_BRF_01200] AUTOSAR OS shall be backwards compatible to OSEK OS

要符合OSEK OS标准

4.2.2 [RS_BRF_01208] AUTOSAR OS shall support to start lists of tasks regularly

任务调度需要有一个任务列表

4.2.3 [RS_BRF_01216] AUTOSAR OS shall support to synchronize ScheduleTables to an outside time source

调度表需要支持可同步时间

4.2.4 [RS_BRF_01232] AUTOSAR OS shall support isolation and protection of application software and BSW

给SWC和BSW做不同的保护，相当于权限不一致。

4.2.5 [RS_BRF_01234] AUTOSAR OS shall support isolation and protection between BSW modules

模块之间的保护，应该将标准的功能实现和拓展的需求实现分开。标准+拓展。利于复用和移植。

4.2.6 [RS_BRF_01240] AUTOSAR OS shall support communication between OSApplications

需要支持OS应用之间的通信机制。在多OSApplications和多核之间传递一些数据。

4.2.7 [RS_BRF_01248] AUTOSAR OS shall support to terminate and restart OSApplications

OSApplications可以终止和重启

4.2.8 [RS_BRF_01256] AUTOSAR OS shall offer support to switch off cores

如何检测到没有task执行，那应该关掉核心来节能。如果没有给核3分配task那应该关掉它。

4.2.9 [RS_BRF_01264] AUTOSAR OS shall support multi-core deadlock free mutual exclusion

需要一个不会死锁的互斥机制来支持多核

4.2.10 [RS_BRF_01272] AUTOSAR OS shall offer functionality to allow Software Components time measurement

提供一个时间测量的功能，来测量任务执行的时长，用来观察任务的负载，以及占用的时长。

Runtime Environment (RTE)

4.3.1 [RS_BRF_01280] AUTOSAR RTE shall offer the external interfaces between Software Components and between Software Components and BSW

需要提供接口传递数据 + 传递函数

4.3.2 [RS_BRF_01288] AUTOSAR RTE interfaces shall be independent of the addressee

需要支持不同的ECU、SWC之间的数据传递

4.3.3 [RS_BRF_01296] AUTOSAR RTE shall support and handle single and multiple instantiation of Software Components

支持多实例化，也就是整个数组或链表

4.3.4 [RS_BRF_01304] AUTOSAR RTE shall support broadcast communication

支持多播

4.3.5 [RS_BRF_01312] AUTOSAR RTE shall support procedure-call communication

支持过程调用通信，例如调用系统服务，NVRAM管理服务

4.3.6 [RS_BRF_01316] AUTOSAR RTE shall support data transformation transparent to the Software Components

支持数据的修改添加等。添加校验位等

4.3.7 [RS_BRF_01317] AUTOSAR shall support SOME/IP

支持SOME/IP。SOME/IP是为以太网设计的串行化和RPC协议

4.3.8 [RS_BRF_01320] AUTOSAR RTE shall schedule SWC and BSW modules

在这里调度SWC和BSW。在OS中启动OS的调度，根据OStask中的配置启动RTE中的调度

4.3.9 [RS_BRF_01328] AUTOSAR RTE shall support scheduling of executable entities on defined events

调度时需要明确是定时调度/中断触发/某某事件触发

4.3.10 [RS_BRF_01336] AUTOSAR RTE shall only run software component runnables inside tasks

不在中断中处理，而是中断中设置事件，RTE根据事件处理

4.3.11 [RS_BRF_01344] AUTOSAR RTE shall support Software Component global data

要有一些全局数据来处理不同运行实体的数据交互

4.3.12 [RS_BRF_01352] AUTOSAR RTE shall offer direct read/write data access, and alternatively pre-read data before a runnable is called and post-write data after the runnable returns

RTE应提供直接的读写数据或在运行实体被调用之前预读

4.3.13 [RS_BRF_01360] AUTOSAR RTE shall support explicit protection mechanisms against concurrent access

应该防止并发

4.3.14 [RS_BRF_01368] AUTOSAR RTE shall support calibration data

支持校准数据

4.3.15 [RS_BRF_01376] AUTOSAR RTE shall support automatic re-scaling and conversion of port data elements

数据的缩放与转换在RTE完成

4.3.16 [RS_BRF_01384] AUTOSAR RTE shall support automatic range checks of data

自动检查数据的有效范围

4.3.17 [RS_BRF_01392] AUTOSAR RTE shall support a bypass implementation

支持旁路的实现，可以将已有的代码集成在Autosar的RTE中

4.3.18 [RS_BRF_01393] AUTOSAR RTE shall support a bypass selectable after generation of an ECU image

支持配置旁路的运行于禁止。

Use Case : A bypass user extends the functionality of a power-train ECU to perform experimental validation of new algorithms.

4.3.19 [RS_BRF_01394] AUTOSAR shall support a memory interface for RTE-managed buffer access

支持RTE缓冲区内存管理接口

4.3.20 [RS_BRF_01395] AUTOSAR shall support synchronization points for buffer access

支持缓冲区访问同步点

4.3.21 [RS_BRF_01400] AUTOSAR RTE shall offer configurable test hooks

提供可配置的hook用来测试

Services

4.4.1 [RS_BRF_01408] AUTOSAR shall provide a service layer that is accessible from each basic software layer

管理功能必须对系统所有模块和层可用。管理功能的接口称为服务

4.4.2 [RS_BRF_01416] AUTOSAR services shall support standardized handling of non-volatile memory data

提供NVM服务，独立于硬件，支持并发

4.4.3 [RS_BRF_01424] AUTOSAR services shall support communication services

提供通信服务

4.4.4 [RS_BRF_01432] AUTOSAR services shall support system time services

提供时间服务

4.4.5 [RS_BRF_01440] AUTOSAR services shall support system diagnostic functionality

提供基本的诊断服务

4.4.6 [RS_BRF_01448] AUTOSAR services shall support mode and state management

提供模式和状态管理

4.4.7 [RS_BRF_01456] AUTOSAR services shall provide system wide cryptographic functionality

提供加密服务

4.4.8 [RS_BRF_01464] AUTOSAR services shall support standardized handling of watchdogs

提供看门狗服务

4.4.9 [RS_BRF_01468] AUTOSAR services shall support time services for relative time measurement

提供时间测量服务 Use Case : Time measurement, timeout supervision, busy waiting

Mode Management

4.5.1 [RS_BRF_01472] AUTOSAR shall support modes

支持模式管理

4.5.2 [RS_BRF_01480] AUTOSAR shall support software component local modes, ECU global modes, and system wide modes

支持软件的范围管理，支持不同的范围模式

software component local
ECU global
system wide

4.5.3 [RS_BRF_01488] AUTOSAR RTE and BSW shall support standardized modes for ECU start up, ECU shut down with restart, and for putting an ECU to sleep

支持对ECU的模式管理

4.5.4 [RS_BRF_01496] AUTOSAR shall standardize how events which move an ECU out of the SLEEP mode are handled

模式的切换应该设计详细的事件来触发和追踪

4.5.5 [RS_BRF_01504] AUTOSAR shall handle memory corruption resulting from ECU sleep

进入SLEEP模式时应该对内存进行校验计算，用于唤醒时对数据的校验

4.5.6 [RS_BRF_01512] AUTOSAR mode management shall support standardized modes for handling of communication buses

对通信总线的模式管理

4.5.7 [RS_BRF_01520] AUTOSAR RTE shall automatically adapt the runnable management on a mode switch

RTE需要自适应不同mode的运行

4.5.8 [RS_BRF_01528] AUTOSAR mode management shall perform actions based on the evaluation of configured rules

模式管理应提供运行时的配置规则与评估规则

4.5.9 [RS_BRF_01536] For system wide modes, AUTOSAR mode management shall forward ECU local mode requests to all involved ECUs

模式管理应该支持将模式请求发送给相关的ECU

Communication via Bus

4.6.1 [RS_BRF_01544] AUTOSAR communication shall define transmission and reception of communication data

通信应定义数据如何处理、如何发送以及如何接收显示的

这里有看到一种很优美的写方法供大家学习。是不是很清晰！

/* Table of service (instance) relevant information. */
const DescSvcInst g_descSvcInst[kDescSvcInstNumItems] =
{ /*DescMsgLen, {DescStateInfo} ,DescSetStateIndex, DescPostHandlerIndex,DescMainHandler*/
  {   2, 0x03, 0x03, 1, { 0x03, 0x07, 0x00 },                      0,    0, DescOemStartSessionDefault } /* $10 $1 */,
  {   2, 0x03, 0x03, 1, { 0x03, 0x07, 0x00 },                      1,    0, DescOemStartSessionProgramming } /* $10 $2 */,
  {   2, 0x03, 0x03, 1, { 0x03, 0x07, 0x00 },                      2,    0, DescOemStartSessionExtended } /* $10 $3 */,
  {   2, 0x03, 0x03, 1, { 0x03, 0x07, 0x00 }, kDescStateNoTransition,    0, ApplDescEcuResetHard } /* $11 $1 */,
  {   2, 0x03, 0x03, 1, { 0x03, 0x07, 0x00 }, kDescStateNoTransition,    0, ApplDescEcuResetSoft } /* $11 $3 */,
  {   4, 0x03, 0x03, 0, { 0x03, 0x07, 0x00 }, kDescStateNoTransition,    0, DescOemClearDiagInfo } /* $14 */,
  {   3, 0x03, 0x03, 0, { 0x03, 0x07, 0x00 }, kDescStateNoTransition,    3,  ApplDescUserServiceHandler } /* $19 $1 ----by Evan, original DescMainHandler:DescOemReadDtcRNODTCBSM*/,
  {   3, 0x03, 0x03, 0, { 0x03, 0x07, 0x00 }, kDescStateNoTransition,    3,  ApplDescUserServiceHandler } /* $19 $2 ----DescOemReadDtcRDTCBSM*/,

  {   2, 0x03, 0x03, 0, { 0x03, 0x07, 0x00 }, kDescStateNoTransition,    3,  ApplDescUserServiceHandler } /* $19 $3 ----DescOemReadDtcRDTCSSI*/,
  {   6, 0x03, 0x03, 0, { 0x03, 0x07, 0x00 }, kDescStateNoTransition,    3,  ApplDescUserServiceHandler } /* $19 $4 -----DescOemReadDtcRDTCSSBDTC*/,
  {   2, 0x03, 0x03, 0, { 0x03, 0x07, 0x00 }, kDescStateNoTransition,    3,  ApplDescUserServiceHandler } /* $19 $A ----DescOemReadDtcRSUPDTC*/,
  {   0, 0x03, 0x03, 0, { 0x03, 0x07, 0x00 }, kDescStateNoTransition,    2, DescReadDataByIdentifier } /* $22 */,
  {   2, 0x03, 0x03, 0, { 0x03, 0x07, 0x00 }, kDescStateNoTransition,    0, DescOemGetRequestSeedLevel1 } /* $27 $1 */,//6rd, from 6 to 2,for SAIC Proj
  {  18, 0x03, 0x03, 0, { 0x03, 0x07, 0x00 },                      3,    0, DescOemSendSend_KeyLevel1 } /* $27 $2 */,//6rd, from 6 to 2,for SAIC Proj
  {   2, 0x01, 0x03, 0, { 0x03, 0x07, 0x00 }, kDescStateNoTransition,    0, DescOemGetRequestSeed_Level3 } /* $27 $05 */,
  {   2, 0x01, 0x03, 0, { 0x03, 0x07, 0x00 },                      4,    0, DescOemSendSendKey_Level3 } /* $27 $06 */,

  {   3, 0x03, 0x03, 1, { 0x03, 0x07, 0x00 }, kDescStateNoTransition,    1, DescOemCommCtrlEnableRxEnableTx } /* $28 $0 */,
  {   3, 0x03, 0x03, 1, { 0x03, 0x07, 0x00 }, kDescStateNoTransition,    1, DescOemCommCtrlEnableRxDisableTx } /* $28 $1 */,
  {   3, 0x03, 0x03, 1, { 0x03, 0x07, 0x00 }, kDescStateNoTransition,    1, DescOemCommCtrlDisableRxEnableTx } /* $28 $2 */,
  {   3, 0x03, 0x03, 1, { 0x03, 0x07, 0x00 }, kDescStateNoTransition,    1, DescOemCommCtrlDisableRxDisableTx } /* $28 $3 */,
  {   8, 0x03, 0x03, 0, { 0x03, 0x07, 0x00 }, kDescStateNoTransition,    0, ApplDescWriteDidF102 } /* $2E $F1 $02 */,
  { 295, 0x03, 0x03, 0, { 0x03, 0x07, 0x00 }, kDescStateNoTransition,    0, ApplDescWriteDidD01C } /* $2E $D0 $1C */,
  {   9, 0x03, 0x03, 0, { 0x03, 0x07, 0x00 }, kDescStateNoTransition,    0, ApplDescWriteDidF18A } /* $2E $F1 $8A */,
  {   7, 0x03, 0x03, 0, { 0x03, 0x07, 0x00 }, kDescStateNoTransition,    0, ApplDescWriteDidF18C } /* $2E $F1 $8C */,
  {   0, 0x03, 0x03, 0, { 0x03, 0x07, 0x00 }, kDescStateNoTransition,    0, DescRoutineControlByIdentifier } /* $31 */,//daoshu 5, from 7 to 3,for Vikeer Proj

  {  11, 0x03, 0x02, 0, { 0x02, 0x07, 0x00 }, kDescStateNoTransition,    0, ApplDescRequestDownload } /* $34 */,//daoshu 5, from 4 to 3,for Vikeer Proj
  {   0, 0x03, 0x02, 0, { 0x02, 0x07, 0x00 }, kDescStateNoTransition,    0, ApplDescTransferData } /* $36 */,//daoshu 5, from 4 to 3,for Vikeer Proj
  {   1, 0x03, 0x02, 0, { 0x02, 0x07, 0x00 }, kDescStateNoTransition,    0, ApplDescRequestTransferExit } /* $37 */,//daoshu 5, from 4 to 3,for Vikeer Proj
  {   2, 0x03, 0x03, 1, { 0x03, 0x07, 0x00 }, kDescStateNoTransition,    0, DescOemProcessTesterPresent } /* $3E $0 */,
  {   2, 0x03, 0x03, 1, { 0x03, 0x07, 0x00 }, kDescStateNoTransition,    0, DescOemControlDtcSettingEnable } /* $85 $1 */,
  {   2, 0x03, 0x03, 1, { 0x03, 0x07, 0x00 }, kDescStateNoTransition,    0, DescOemControlDtcSettingDisable } /* $85 $2 */,
  {   0, 0x03, 0x03, 0, { 0x03, 0x07, 0x00 }, kDescStateNoTransition,    4, ApplDescUserServiceHandler } /* $FF */
};

4.6.2 [RS_BRF_01552] AUTOSAR communication shall separate bus independent functionality from bus dependent functionality

应该将总线独立功能与总线依赖功能分开

4.6.3 [RS_BRF_01560] AUTOSAR communication shall support mapping of signals into transferrable protocol data units

Autosar通信应处理信号和数据之间的映射（信号/数据类型到总线里数据实体的映射）

4.6.4 [RS_BRF_01568] AUTOSAR communication stack shall support fixed size and dynamic size signals

支持动态大小的数据

4.6.5 [RS_BRF_01576] AUTOSAR communication shall support a signal gateway

支持作为信号网关，及接收信号后原封不动的再发送出去

4.6.6 [RS_BRF_01584] AUTOSAR communication shall support an IPDU gateway

支持IPDU网关

4.6.7 [RS_BRF_01592] AUTOSAR communication shall offer data transfer on user request, time based, and requested via the underlying bus

通过请求的模式来提供传输。请求buffer后将数据拷贝到指定的位置后发起传输

4.6.8 [RS_BRF_01600] AUTOSAR communication shall support time-out handling

支持超时处理

4.6.9 [RS_BRF_01608] AUTOSAR communication shall support to filter signals

支持信号/数据的过滤

4.6.10 [RS_BRF_01616] AUTOSAR communication shall support initial values for signals

为了防止在写入之前就被读出，处理数据应该支持初始化的信号/数据

4.6.11 [RS_BRF_01624] AUTOSAR communication shall support data conversion between big endian and little endian data representation

支持大小端转换

4.6.12 [RS_BRF_01632] AUTOSAR communication shall support data consistency of groups of signals

要保证信号组数据的一致性

4.6.13 [RS_BRF_01640] AUTOSAR communication shall support transmit and receive cancelation

通信支持取消正在发送和接收的处理

4.6.14 [RS_BRF_01648] AUTOSAR communication shall support transfer of data sizes larger than the maximum transmission unit of the underlying bus

支持传输数据的大小不受底层的限制

4.6.15 [RS_BRF_01649] AUTOSAR communication shall support communication of large and dynamic data in a dedicated optimized module

应该在专门的优化模块中支持大数据和动态数据处理

4.6.16 [RS_BRF_01656] AUTOSAR communication shall support XCP

支持XCP，XCP是汽车测试中使用最广泛的协议

4.6.17 [RS_BRF_01660] AUTOSAR communication shall support distribution and synchronization of a Global Time across different networks

应该提供在不同网络（CAN、FlexRay、以太网）分发、同步、级联全局时间的机制

4.6.18 [RS_BRF_01664] AUTOSAR communication shall support a state management of buses

支持总线的状态管理

4.6.19 [RS_BRF_01672] AUTOSAR communication state management shall support dynamic bus access limitation

通信状态管理应支持动态总线访问限制

4.6.20 [RS_BRF_01680] AUTOSAR communication shall support mechanism to keep a bus awake, and to be kept awake by a bus

应该有保持总线唤醒的机制和被总线唤醒机制

4.6.21 [RS_BRF_01688] AUTOSAR communication shall support to put buses synchronously to sleep

支持总线同步休眠

4.6.22 [RS_BRF_01696] AUTOSAR communication shall support selective shutdown of nodes while bus communication is active

支持激活总线节点后的关闭节点

Communication buses

4.7.1 [RS_BRF_01704] AUTOSAR communication shall support the CAN communication bus

支持CAN

4.7.2 [RS_BRF_01712] AUTOSAR communication shall support the adaptable speed offered by CAN FD

支持CAN FD

4.7.3 [RS_BRF_01716] AUTOSAR communication shall support to aggregate multiple PDUs to one PDU dynamically

支持将多个PDU聚合为一个PDU

4.7.4 [RS_BRF_01720] AUTOSAR communication shall support the standardized transport protocol for Diagnostics over CAN

支持基于CAN的诊断

4.7.5 [RS_BRF_01728] AUTOSAR communication shall support J1939 transport protocol

支持J1939

4.7.6 [RS_BRF_01736] AUTOSAR communication shall support dynamic allocation of addresses as requested by J1939 network management

支持动态地址分配

4.7.7 [RS_BRF_01744] AUTOSAR communication shall support TTCAN

支持TTCAN（TTCAN是CAN的超集，添加了时间触发机制）

4.7.8 [RS_BRF_01752] AUTOSAR communication shall support FlexRay

支持FlexRay

4.7.9 [RS_BRF_01760] AUTOSAR communication shall support the standardized transport protocol for Diagnostics on FlexRay

基于FlexRay的诊断

4.7.10 [RS_BRF_01768] AUTOSAR communication shall support LIN

支持LIN

4.7.11 [RS_BRF_01770] AUTOSAR communication shall support LIN transport protocol

支持LINTP

4.7.12 [RS_BRF_01776] AUTOSAR communication shall support Ethernet

支持Ethernet

4.7.13 [RS_BRF_01784] AUTOSAR communication shall support the IP protocol stack

支持IP相关AUTOSAR communication shall support the IP protocol stack. This includes e. g. IPv4, IPv6, UDP, TCP, ARP, NDP, DHCP, ICMP, ICMPv6, IPsec

4.7.14 [RS_BRF_01788] AUTOSAR communication shall support the standardized diagnostic communication over Internet Protocol

支持基于因特网（Internet）的诊断

4.7.15 [RS_BRF_01792] AUTOSAR shall support SPI

支持SPI

Memory Stack

4.8.1 [RS_BRF_01800] AUTOSAR non-volatile memory functionality shall be divided into a hardware dependent and independent layer

NVM应该分层，硬件依赖和硬件独立

4.8.2 [RS_BRF_01808] AUTOSAR non-volatile memory handling shall support different kinds of memory hardware

应该进行抽象支持不同种类的硬件

4.8.3 [RS_BRF_01812] AUTOSAR non-volatile memory functionality shall support the prioritization and asynchronous execution of jobs

应该支持优先级和异步执行

4.8.4 [RS_BRF_01816] AUTOSAR non-volatile memory functionality shall organize persistent data based on logical memory blocks

支持有效的阻止持久数据，组织数据存储

4.8.5 [RS_BRF_01824] AUTOSAR non-volatile memory functionality shall provide a mapping of non-volatile memory into random access memory

提供NVM到RAM的映射

4.8.6 [RS_BRF_01832] AUTOSAR non-volatile memory shall handle logical memory blocks independent of its physical address

使逻辑块独立于物理块

4.8.7 [RS_BRF_01840] AUTOSAR non-volatile memory functionality shall secure integrity of memory blocks

应保证内存的完整性，当发现损坏的内存块时才去相应的行动。也支持数据冗余存储来保证数据的完整性

4.8.8 [RS_BRF_01844] AUTOSAR non-volatile memory shall support write protection for memory blocks

支持写保护

4.8.9 [RS_BRF_01848] AUTOSAR non-volatile memory functionality shall provide mechanisms to enhance hardware reliability

提高硬件可靠性的机制，分散写入避免固定存储单元寿命不均匀

4.8.10 [RS_BRF_01850] AUTOSAR non-volatile memory functionality shall be able to cope with hardware lifetime constraints

对硬件寿命的控制

Microcontroller Abstraction and I/O

4.9.1 [RS_BRF_01856] AUTOSAR microcontroller abstraction shall provide access to internal MCU configuration

微控制器抽象应提供对内部MCU的配置

4.9.2 [RS_BRF_01864] AUTOSAR microcontroller abstraction shall provide mapping of I/O signals to digital I/O ports

微控制器抽象应提供对信号I/O到数字I/O的映射

4.9.3 [RS_BRF_01872] AUTOSAR microcontroller abstraction shall provide mapping of I/O signals to analog/digital converter ports

微控制器抽象应提供对I/O信号到模拟/数字转换port的映射

4.9.4 [RS_BRF_01880] AUTOSAR microcontroller abstraction shall provide mapping of I/O signals to pulse-width modulation controlled ports

微控制器抽象应提供对I/O信号到PWM port的映射

4.9.5 [RS_BRF_01888] AUTOSAR microcontroller abstraction shall provide mapping of I/O signals to an output compare unit

微控制器抽象应提供对I/O信号到输出比较单元的映射

4.9.6 [RS_BRF_01896] AUTOSAR microcontroller abstraction shall provide mapping of I/O signals to input capture units

微控制器抽象应提供对I/O信号到输入比较单元的映射

4.9.7 [RS_BRF_01904] AUTOSAR microcontroller abstraction shall provide access to hardware timers

微控制器抽象应提供对硬件定时器的使用

4.9.8 [RS_BRF_01912] AUTOSAR microcontroller abstraction shall provide access to SPI

微控制器抽象应提供对SPI的访问

4.9.9 [RS_BRF_01920] AUTOSAR microcontroller abstraction shall provide access to communication bus controllers

微控制器抽象应提供对通信总线控制器的访问

4.9.10 [RS_BRF_01928] AUTOSAR microcontroller abstraction shall provide access to non-volatile memory hardware

微控制器抽象应提供对非易失性存储器硬件的访问

4.9.11 [RS_BRF_01936] AUTOSAR microcontroller abstraction shall provide access to MCU internal and external hardware watchdogs

微控制器抽象应提供对内部或者外部硬件看门狗的访问

4.9.12 [RS_BRF_01944] AUTOSAR microcontroller abstraction shall provide access to communication bus watchdog hardware

微控制器抽象应提供对通信总线看门狗硬件的访问

4.9.13 [RS_BRF_01946] AUTOSAR microcontroller abstraction shall provide access to cryptographic hardware

微控制器抽象应提供对加密硬件的访问

4.9.14 [RS_BRF_01952] AUTOSAR IO Hardware Abstraction shall support standardized modes for connected I/O devices

I/O硬件抽象应支持链接I/O设备的标准化模式

4.9.15 [RS_BRF_01960] AUTOSAR IO Hardware Abstraction shall provide mapping of I/O signals between domain specific and hardware specific units

I/O硬件抽象应提供域特定单元和硬件特定单元之间的I/O信号映射

4.9.16 [RS_BRF_01968] AUTOSAR IO Hardware Abstraction shall support edge triggered I/O signals

I/O硬件抽象应支持边缘触发I/O信号

4.9.17 [RS_BRF_01976] AUTOSAR IO Hardware Abstraction shall support level triggered I/O signals

I/O硬件抽象应支持高电平触发I/O信号

4.9.18 [RS_BRF_01984] AUTOSAR IO Hardware Abstraction shall support time domain I/O signals

I/O硬件抽象应支持时域I/O信号

4.9.19 [RS_BRF_01992] AUTOSAR IO Hardware Abstraction shall support frequency domain I/O signals

I/O硬件抽象应支持频域I/O信号

4.9.20 [RS_BRF_02000] AUTOSAR IO Hardware Abstraction shall protect hardware against illegal operation

I/O硬件抽象应支持保护硬件免受非法操作

Security

4.10.1 [RS_BRF_02008] AUTOSAR shall provide mechanisms to protect the system from unauthorized read access

应提供保护系统免受未经授权的读取访问的机制

4.10.2 [RS_BRF_02016] AUTOSAR shall provide mechanisms to protect the system from unauthorized modification

应提供保护系统免受未经授权的修改的机制

4.10.3 [RS_BRF_02024] AUTOSAR shall provide mechanisms to protect the system from unauthorized use

应提供保护系统免受未经授权的使用机制

4.10.4 [RS_BRF_02031] AUTOSAR shall provide uniform access to cryptographic solutions implemented either by software or hardware

应提供对通过软件或硬件实现的加密解决方案的统一访问

4.10.5 [RS_BRF_02032] AUTOSAR security shall allow integration of cryptographic primitives into the cryptographic service manager

安全性应允许将加密原语集成到加密服务管理器中

4.10.6 [RS_BRF_02033] AUTOSAR shall provide concurrent access to cryptographic services

应提供对加密服务的并发访问

4.10.7 [RS_BRF_02035] AUTOSAR shall support Message Data Authentication

应支持报文数据认证

4.10.8 [RS_BRF_02036] AUTOSAR shall support Message Data Freshness Verification

应支持报文数据新鲜度验证

4.10.9 [RS_BRF_02037] AUTOSAR shall support Message Data Integrity Verification

应支持报文数据完整性验证

4.10.10 [RS_BRF_02038] AUTOSAR shall support Intrusion Detection System (IDS) security controls

应支持入侵检测系统(IDS)安全控制

Safety

4.11.1 [RS_BRF_02040] AUTOSAR BSW and RTE shall ensure data consistency

BSW和RTE应确保数据的一致性

4.11.2 [RS_BRF_02048] AUTOSAR shall support usage of hardware memory protection features to enhance safety

应支持使用硬件内存保护功能以增强安全性

4.11.3 [RS_BRF_00129] AUTOSAR shall support data corruption detection and protection

应支持数据损坏检测和保护

4.11.4 [RS_BRF_00131] AUTOSAR shall support program flow monitoring

应支持程序流监控

4.11.5 [RS_BRF_02056] AUTOSAR OS shall support timing protection

OS应支持定时保护

4.11.6 [RS_BRF_02064] AUTOSAR shall use hardware communication data integrity mechanisms

应使用硬件通信数据完整性机制

4.11.7 [RS_BRF_00110] AUTOSAR shall offer safety mechanisms to protect safety-related data communication against communication errors

应提供安全机制，以保护与安全有关的数据通信免受通信错误的影响

4.11.8 [RS_BRF_00113] AUTOSAR shall detect signal time-outs

应检测信号超时

4.11.9 [RS_BRF_00241] AUTOSAR shall support redundant multiple communication links

应支持冗余的多个通信链路

4.11.10 [RS_BRF_02068] AUTOSAR methodology shall allow to allocate safety properties to model elements

方法论应允许将安全属性分配给模型元素

Libraries

4.12.1 [RS_BRF_02072] AUTOSAR shall provide generic functionality which is in wide use in the automotive domain as libraries

应作为库提供在汽车领域广泛使用的通用功能

4.12.2 [RS_BRF_02080] AUTOSAR libraries shall use C interfaces

库应使用C接口

4.12.3 [RS_BRF_02088] AUTOSAR library functionality shall be reentrant

库功能应是可重入的

4.12.4 [RS_BRF_02096] AUTOSAR shall provide checksum computation of cyclic redundancy check sums as a library

应作为库提供循环冗余校验和的校验和计算

4.12.5 [RS_BRF_02104] AUTOSAR shall provide end-to-end protection algorithms as a library

应作为库提供端到端保护算法

4.12.6 [RS_BRF_02112] AUTOSAR shall support floating point arithmetic functions as a library

应支持作为库的浮点算术函数

4.12.7 [RS_BRF_02120] AUTOSAR shall support fixed point arithmetic functions as a library

应支持定点算术函数作为库，提供基本的算法库。排序、过滤等等

4.12.8 [RS_BRF_02128] AUTOSAR shall provide arithmetic interpolation routines as a library

应提供算术插值例程作为库

4.12.9 [RS_BRF_02136] AUTOSAR shall provide cryptographic primitives as a library

应提供加密原语作为库

Diagnostic and Error Handling

4.13.1 [RS_BRF_02144] AUTOSAR diagnostic shall provide standardized diagnostic services for external testers

诊断应为外部测试人员提供标准化的诊断服务

4.13.2 [RS_BRF_02152] AUTOSAR diagnostic shall provide standardized bootloader interaction

诊断应提供标准化的引导加载程序交互（bootloader）

4.13.3 [RS_BRF_02160] AUTOSAR diagnostic shall allow external testers to control active functionality of the ECU

诊断应允许外部测试人员控制ECU的活动功能 disable faulty and/or dangerous functionality (like airbag ignition)

4.13.4 [RS_BRF_02168] AUTOSAR diagnostics shall provide a central classification and handling of abnormal operative conditions

诊断应对异常手术条件进行集中分类和处理

4.13.5 [RS_BRF_02176] AUTOSAR error handling shall distinguish between defined abnormal operative conditions and unexpected exceptions from intended behavior

错误处理应区分定义的异常操作条件和预期行为的意外异常

4.13.6 [RS_BRF_02184] AUTOSAR diagnostics shall provide central storage to document occurrences of fault conditions

诊断应提供中央存储，以记录故障条件的出现

4.13.7 [RS_BRF_02192] AUTOSAR diagnostic management shall be bus independent

诊断管理应与总线无关

4.13.8 [RS_BRF_02200] AUTOSAR diagnostic shall provide external access to internal configuration and calibration data

诊断应提供对内部配置和校准数据的外部访问

4.13.9 [RS_BRF_02208] AUTOSAR diagnostic shall use authentication mechanisms to secure external access

诊断应使用认证机制来确保外部访问的安全

4.13.10 [RS_BRF_02216] AUTOSAR diagnostic shall allow runtime degradation of faulty functionality to maintain minimum ECU/vehicle operability

诊断应允许故障功能在运行时降级，以保持最低ECU/车辆可操作性

Test and Debugging

4.14.1 [RS_BRF_02224] AUTOSAR shall support run-time hardware tests

应支持运行时硬件测试

4.14.2 [RS_BRF_02232] AUTOSAR shall support development with run-time assertion checks

应支持具有运行时断言检查的开发

4.14.3 [RS_BRF_02264] AUTOSAR shall support XCP for setting measurement and calibration data

应支持用于设置测量和校准数据的XCP

4.14.4 [RS_BRF_02272] AUTOSAR shall offer tracing of application software behavior

应提供应用软件行为的跟踪

Integration and Migration

4.15.1 [RS_BRF_02280] AUTOSAR shall support non-AUTOSAR BSW modules

应支持非AutoSar的BSW模块

4.15.2 [RS_BRF_02288] Generic interfaces in AUTOSAR shall support Complex Drivers

AUTOSAR中的通用接口应支持复杂驱动程序

Standardization and Documentation

4.16.1 [RS_BRF_04000] AUTOSAR documentation shall support traceability

文档应支持可追溯性

4.16.2 [RS_BRF_04008] AUTOSAR documentation shall support consistency and quality assurance

文档应支持一致性和质量保证

4.16.3 [RS_BRF_04016] AUTOSAR shall support modeling and documentation guidelines

应支持建模和文件编制指南

4.16.4 [RS_BRF_04024] AUTOSAR shall support guidance for applying the specifications

应支持规范应用指南

二、VFB虚拟功能总线

来了解一下吧

1 Introduction to this document

1.1 Contents

This specification describes the AUTOSAR Virtual Functional Bus (VFB).

虚拟功能总线

1.3 Relationship to other AUTOSAR specifications

整个规范的关系，VFB算是比较上层的

1.4 Structure and conventions of this document

2 The Virtual Functional Bus

AUTOSAR的方法论描述了几个部分的关系

Basic Software
System
Virtual Functional Bus
Software Component

这里可以看到VFB的作用

In AUTOSAR, an application is modeled as a composition of interconnected components. This is illustrated in the top half of Figure 2.2 (labeled "VFB view"). The "virtual functional bus" is the communication mechanism that allows these components to in teract. The components are mapped on specific system resources (ECUs). Thereby, the virtual connections between the components are mapped onto local connections (within a single ECU) or on network-technology specific communication mechanisms (such as CAN or FlexRay frames). Finally, the individual ECUs in such a system can be configured. The concrete interface between the individual components and between the components and the Basic Software (BSW) 4 is called the Run-Time Environment (RTE) [7]

VFB是这些组件的交互机制

组件与组件之间和组件与BSW之间被叫做RTE

A component encapsulates complete or partial automotive functionality. Components consist of an implementation and of an associated formal software-component description (defined in the "Software Component Template" specification [6]). The concept of the virtual functional bus allows for a strict separation between applications and infrastructure. The software components implementing the application are largely in dependent of the communication mechanisms through which the component interacts with other components or with hardware (such as sensor or actuators). This fulfills AUTOSAR’s goal of relocatability (see also AUTOSAR "Main Requirements" [1]).

RTE将组件与组件之间和组件与BSW之间分离，不再依赖。实现软件组件的独立。

With this the complete communication of a system can be specified including all com munication sources and sinks. The VFB can therefore be used for plausibility checks concerning the communication of software components. The communication connections and the connected software components are saved in one description, which will be used for the next process steps (mapping, software configuration, etc.).

The VFB specification needs to provide concepts for all infrastructure-services that are needed by a component implementing an automotive application. These include:

Communication to other components in the system

Communication to sensors and actuators in the system (see Chapter 6, Interaction with hardware)

Access to standardized services, such as reading to or writing from non-volatile ram (see Chapter 7, AUTOSAR Services)

Responding to mode-changes, such as changes in the power-status of the local ECU (see Chapter 8, Mode Management)

Interacting with calibration and measurement systems (see Chapter 10)

VFB提供以下概念：

组件通信
传感器和执行器通信
标准服务的通过
模式管理
与校准和测量系统的交互

3 Overall mechanisms and concepts

3.1 Components

The central structural element used when building a system at the VFB-level is the "component". A component has well-defined "ports", through which the component can interact with other components. A port always belongs to exactly one component and represents a point of interaction between a component and other components.

组件之间通过port进行交互

Figure 3.1 shows an example of the definition of a component-type called "SeatHeating Control", which controls the heating element in a seat based on several information sources.

In this example, the component-type requires the following information as input:

whether a passenger is sitting on the seat (through the port "SeatSwitch")

the setting of the seat temperature dial (through the port "Setting")

and some information from a central power management system (through the port "PowerManagement"), which could decide to disable seat heating in certain conditions.

It controls

the DialLED that is associated with the seat temperature dial (port "DialLED")

and the heating element (through the port "HeatingElement").

Finally, the component can be calibrated (port "Calibration"), needs the status of the ECU on which the component runs (port "ecuMode") and requires access to local nonvolatile memory (port "nv").

一个例子：

SeatHeatingControl:座椅加热控制
- DialLED灯
- HeatingElement加热元件
- SeatSwitch座位开关
- Setting设置
- PowerManagement电源管理
- 输入
- 输出
- Calibration校准
- ecuMode ECU模式
- nv NVM访问

Figure 3.2 shows an example of the definition of a sensor-actuator component1 called "SeatHeating". This component inputs the desired setting of the heating element (through the port "Setting") and directly controls the seat heating hardware (through the port "IO").

SeatHeating
- Setting 通过这个port给座椅加热控制提供必要的设置
- IO 通过这直接控制硬件

AUTOSAR supports multiple instantiation of components.

可以创建多个实例

[EXP_VFB_00001] At configuration time, the component’s ports are known()

[EXP_VFB_00002] d Components interact with each other through their ports only ()

[EXP_VFB_00084] d A component-type can be instantiated multiple times on the VFB()

3.2 Port-Interfaces接口

A port of a component is associated with a "port-interface". The port-interface defines the contract that must be fulfilled by the port providing or requiring that interface.

[EXP_VFB_00003] At configuration time, each port is typed by exactly one port interface()

KIND OF PORT-INTERFACE	接口类型	接口描述
Client-server	客户端-服务端	函数接口服务端是操作的提供者服务端可以连接多个客户端
Sender-receiver	发送端-接收端	数据接口发送端将信息或事件分发给一个或多个接收端模式管理端可以提醒一个或多个接收端切换模式
Parameter interface	参数接口	用来通过常量参数，不允许在这里传递变量
Non volatile Data Interface	非易失性数据接口	提供非易失性数据的读写接口
Trigger Interface	触发接口	允许一个软件组件触发另一个组件
Mode Switch Interface	模式切换接口	模式切换

A client-server interface defines a set of operations that can be invoked by a client and implemented by a server. Figure 3.4 shows an example of the definition of a simple client-server interface. The interface "HeatingElementControl" defines a single operation called "SetPower" with a single ingoing argument called "Power". The operation can return an application error called "HardwareProblem".

Client-server接口定义了一组由服务端提供的操作

A sender-receiver interface defines a set of data-elements that are sent and received over the VFB. Figure 3.5 shows the definition of a simple sender-receiver interface called "SeatSwitch" containing a single data-element called "PassengerDetected".

Sender-receiver定义一组数据元素

[EXP_VFB_00004] d At configuration time it is known whether the port-interface is a client-server interface or a sender-receiver interfacec ()

[EXP_VFB_00005] d At configuration time, it is known which operations a client-server interface containsc ()

[EXP_VFB_00006] d At configuration time, it is known which data-elements a sender receiver interface containsc ()

AUTOSAR has standardized stable and widely accepted application interfaces to en sure the interoperability of software components from different vendors. The application interfaces aim to cover a wide range of automotive domains.

AutoSar定义了标准的接口

3.3 Ports

As defined before, the ports of a component are the interaction points between components. A port of a component is either a "PPort", a "RPort" or a "PRPort". A "PPort" or a "PRPort" provides the elements defined in a port-interface. A "RPort" or a "PRPort" requires the elements defined in a port-interface. A port is thus typed by exactly one port-interface.

3.3.1 Port Types

RPort

PPort

PRPort

RPort

PPort

PRPort

RPort

PPort

PRPort

RPort

PPort

PRPort

PPort（这个给我看迷糊了，与上面的PPort的差别是一个是实体的一个是只有线条。数据>常量数据）

PPort

例子：

When a PPort of a component provides a client-server interface, the component to which the port belongs provides an implementation of the operations defined in the interface.

Client-Server Interface

Sender-Receiver Interface

3.3.2 Port Compatibility

A receiver port can only be connected to a compatible provider port. Table 3.2 gives an overview over the compatibility of ports. The following comments describe some basic compatibility rules. Please note that this overview only contains some basic rules. A more comprehensive and detailed Port Description is given in the "Software Component Template" [6].

port的兼容性

For each element in the interface of the require port there must be a compatible element in the interface of the provide port. The mapping is realized implicitly via the shortname of the element or explicitly via explicit mappings (see Section 3.9.1).

For mode switch ports all elements of the interface of the provide port must have a corresponding element in the interface of the require port.

Require and provide port are both service ports or are both not service ports.

For connecting ports with Sender Receiver Interface, Parameter Interface or Non Volatile Data Interface, corresponding elements must have compatible implementation policies (see "Software Component Template" [6]).

PRPorts typed by a parameter interface is not supported.

与上面的1-5规则对应

For example, a Require Port that expects a fixed parameter can only be connected to a Port that provides a fixed Parameter. This is because this fixed data may be used in a compilation directive like #if and only macro #define (fixed data) can be compiled in this case.

例如，需要固定参数只能通过Parameter interface

3.3.3 Data Type Policies

Data elements on a port are typed properly as part of the port interface Port Description of a SWC. However it should be noted though that the data type of elements to be communicated between two ports can be overridden by the integrator by overriding the data type using a data type policy which allows for reducing the number of bits to be transmitted over a physical network. The data type has to be compatible and usually result in loss of precision and introduce quantization artifacts.

3.4 Connectors

[EXP_VFB_00008] At configuration time, all components instantiated on the VFB are known()

[EXP_VFB_00009] At configuration time, all communication possibilities between components on the VFB are modeled through the presence of connectors. Communi cation between ports not connected through such a connector is not possible.()

[EXP_VFB_00010] An assembly-connector connects exactly one PPort or PRPort with exactly one RPort or PRPort ()

[EXP_VFB_00113] An assembly-connector can connect one PPort or PRPort with one RPort or PRPort only if their port types, interfaces and attributes, characterizing their communication abilities, are compatible with each other.

3.4.1 Unconnected Ports

未连接的port

3.5 Compositions versus atomic components

A sub-system consisting of usages of components and connectors is packaged into a "composition". In AUTOSAR, the usage of a component-type within a composition is called a "prototype". A composition is itself a component-type and can have its own ports. Compositions can be used as structuring elements to build up hierarchical systems with an arbitrary number of hierarchies.

组件port的组合

A component-type in AUTOSAR is either a "composition" or "atomic". A composition is defined through interconnected prototypes (as in Figure 3.9). An atomic component cannot be further decomposed into smaller components.

组件类型分为：组合或原子

When designing a composition, service ports have to be specially handled. The configuration of AUTOSAR services takes place in the ECU configuration phase by adding the necessary service components and connecting them to the flattened set of atomic software components which require access to the services. As a consequence, compositions are not allowed to have ports for use with services. For more details about services, see AUTOSAR Services.

不允许组合拥有用于服务的port。也就是上面的Service Port。组合不可以掉AutoSar的服务

3.6 Relationship between the VFB and the ECU Software Architecture

When a sub-system consisting of atomic components and assembly-connectors is deployed on a network of ECUs, all atomic components are mapped on an ECU. The corresponding connectors between the components are implemented by intra- or inter ECU communication mechanisms.

可以对VFB有个整体逻辑的概念

3.7 Kinds of software components

感觉没啥需要记的。想了解一下的看官方文档吧。

三、BulkNvDataManager

1 Introduction and functional overview

This specification describes the functionality, API and the configuration for the AUTOSAR Basic Software module BulkNvDataManager.

The demand of non-volatile bulk data is increasing for use-case like variant-coding. Such data is used frequently, but rarely updated. The BulkNvDataManager offers in contrast to the NvM an API to read the data directly from flash memory. In consequence a RAM mirror is avoided, but the writing of the data is more complex.

提供了从flash读取数据的API（BndM）

7 Functional specification

In general the concept how the BulkNvDataManager will manage its flash memory is vendor-specific.

如何管理flash特定于供应商的。因为flash需要按块/页擦除后才能写入。不像RAM可以随时写。

The base idea is to have an A/B switching of the data blocks. This means the complete Bulk NvData will be stored in partition A. When the writing is started (BndM_WriteStart) the B partition needs to be erased. The updated blocks (BndM_WriteBlock) will be written to partition B. The finalization (BndM_WriteFinalize) will finally make partition B consistent (e.g. by coping the not updated blocks over to partition B) and switch the active partition to B (further calls to BndM_GetBlockPtr will point to the data in the partition B). Nevertheless the vendor solution could consider alternative solutions like an update through a FlashBootloader.

整体思想就是分A/B块。原本数据在A，需要更新时将B擦除，原数据从A拷贝到B，更新数据更新到B。然后将活动的分区设置到B。

[SWS_BndM_00001] The BndM shall manage its BndM blocks (BndMBlockDescriptor) in the direct accessible memory (i.e. via pointer).(RS_Diag_04243)

BndM可以直接通过指针访问内存

[SWS_BndM_00002] A call of BndM_GetBlockPtr shall deliver the base pointer to the corresponding BndM block (BndMBlockDescriptor) in the currently active partition.(RS_Diag_04243)

能获取当前活跃块

[SWS_BndM_00003] A call of BndM_WriteStart shall trigger the preparation of the 2nd (free) partition. (RS_Diag_04243)

触发去准备第二个（空闲）块

Note: Depending on the implemented strategy the preparation takes more time. This could be coordinated within the BndM_MainFunction. Note: In case of direct writing access to flash the flash-page needs to be erased.

这个准备的过程可能需要擦除块。需要更多的时间，所以可以在BndM_MainFunction中处理。

Caveat: Depending on the hardware a parallel read and write access to code flash is not possible. In this case the overall ECU needs to be in a writing mode (e.g. Flash Bootloader context or all other tasks are interrupted/stopped).

依赖于硬件，并行读写不太可能，所以需要设置为写模式。例如Flash Bootloader和其他任务都应该被中断/停止

[SWS_BndM_00007] After preparation of the 2nd (free) partition [SWS_BndM_00003] is successfully finished (writing to the 2nd partition is possible) the callback Xxx_BndMWriteStartFinish with the result set to E_OK shall be triggered in the context of the BndM_MainFunction.(RS_Diag_04243)

准备空闲块完成后应该调用Xxx_BndMWriteStartFinish这支API去切换状态

[SWS_BndM_00014] A call of BndM_WriteStart shall be rejected with the error Code E_NOT_OK, if the call is done within an active writing phase (phase between BndM_WriteStart and BndM_WriteFinalize).(RS_Diag_04243)

在写开始去准备空闲块到准备完成期间不允许再次调用。

[SWS_BndM_00004] A call of BndM_WriteBlock shall trigger the writing of the data to the 2nd (unused) partition. The data (ImplementationDataType) shall be not modified to allow a pointer access. (RS_Diag_04243)

BndM_WriteBlock这支API触发数据写入分区

[SWS_BndM_00008] After writing of [SWS_BndM_00004] the 2nd (free) partition is finished the callback Xxx_BndMWriteBlockFinish with the result set to E_OK shall be triggered in the context of the BndM_MainFunction.(RS_Diag_04243)

在写完第二块之后调用Xxx_BndMWriteBlockFinish来切换状态机

[SWS_BndM_00011] A call of BndM_WriteBlock shall be rejected with the error Code E_NOT_OK, if the call is done without a previous call of BndM_WriteStart. or while another writing of the same or another block is ongoing or the call is done within the finalization mode of the BndM.(RS_Diag_04243)

BndM_WriteBlock这个函数必须在调用BndM_WriteStart后调用，同时Xxx_BndMWriteBlockFinish前不能重入

[SWS_BndM_00012] A call of BndM_WriteBlock shall be rejected with the error Code E_NOT_OK, if the call is done while another writing of the same or another block is ongoing.(RS_Diag_04243)

[SWS_BndM_00013] A call of BndM_WriteBlock shall be rejected with the error Code E_NOT_OK, if the call is done within or after the finalization mode of the BndM (RS_Diag_04243)

[SWS_BndM_00005] A call of BndM_WriteFinalize shall trigger the finalization of the 2nd (unused) partition. In background the BndM shall make the 2nd (unused) partition consistent by coping all unchanged BndMBlockDescriptor to the 2nd (unused) partition. If the finalization is successful the BndM shall make the 2nd (unused) partition to the active partition and trigger the callback Xxx_BndMWriteFinalizeFinish with the result set to E_OK.(RS_Diag_04243) Note: Further calls to BndM_GetBlockPtr will point to the data in the 2nd (now active) partition after the finalization is successful.

BndM_WriteFinalize会触发写完成，然后开始处理未改变的数据，BndMBlockDescriptor从A拷贝到B ，之后切换状态完成，最后修改活跃块指针

[SWS_BndM_00009] d If the finalization is NOT successful (the 2nd partition is not consistent and could therefore not be used) the BndM shall keep the current active partition as the active partition and trigger the callback Xxx_BndMWriteFinalizeFinish with the result set to E_NOT_OK.(RS_Diag_04243)

当第二块数据完整性不一致导致不能使用时，BndM应保持当前活跃分区，并调用完成设置未不OK

[SWS_BndM_00010] d A call of BndM_WriteFinalize without a previously called BndM_WriteStart or within the finalization mode of the BndM the DET BndM_E_WRONG_SEQUENCE error shall be thrown.c (RS_Diag_04243)

状态机调度图

四、SecurityOverview

这里介绍了一些攻击的示例

Attacks and Countermeasures

Code Corruption Attack
Control-flow Hijack Attack
Data-only Attack
Information Leak

Existing Solutions

Write xor Execute, Data Execution Prevention (DEP)

Stack Smashing Protection (SSP)

Address Space Layout Randomization (ASLR)

Control-flow Integrity (CFI)

Code Pointer Integrity (CPI), Code Pointer Separation (CPS)

Pointer Authentication

Horizontal Isolation

Virtual Memory
OS-Level Virtualization
Vertical Isolation

五、SafetyOverview

总览

Vehicle Context

冗余

ECU Context

一个简单的ECU设计

Some simple on-board safety measures are:

Regulated and controlled power management
Power monitoring (voltage and current)
Temperature monitoring
Alive monitoring (Watchdog)
Input/output control

Microprocessor Context

Potential Hardware Faults and Safety Measures

Following is a list of typical measures that can be taken in order to detect/avoid the

above mentioned hardware faults:

Cyclic Configuration Test
Cyclic Hardware Part Test (using known test vectors)
Shutdown Path Test ("Can the safe state be reached?")
Memory Walk-Through Tests (e.g. test for writeability)
Clock Monitoring, Power Monitoring, Timing Monitoring (timing predictions may be very inaccurate in high-performance microprocessors due to the inherent com plexity of such systems)
Plausibility Checks (but only applicable if checks are significantly easier to calculate than the functions to be monitored)
External Watchdog
End-to-End Protection
Hardware Lockstep CPU Cores (although this may not always be present in high performance microprocessors)
ECC Memory (Error detection for data and address links)
Redundant Execution (2oo2, 2oo2D, 2oo3)
Proper Hardware Design (the choices in high-performance microprocessors may be very limited due to the complexity of hardware architecture and may result in common cause failures)
Proper Communication Bus
Proper Shielding
Proper Electromagnetic Compatibility (EMC)

Potential Software Faults and Safety Measures

Following is a list of typical measures that can be taken in order to detect/avoid the

above mentioned software faults:

Redundant Execution (2oo2, 2oo2D, 2oo3)
Program Flow Control ("Does the software pass-by known points in the right order?")
Checksums
Arbitration
Collision Detection
Signatures
Software Lockstep
Parallel Execution
Safety Checker